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The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 



A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1 . 1 36(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 
Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1 )K Responsive to communication(s) filed on 20 March 2001 . 
2a)Q This action is FINAL. 2b)S This action is non-final. 

3) D Since this application is in condition for allowance except for formal matters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quay/e, 1935 CD. 1 1 , 453 O.G. 21 3. 

Disposition of Claims 

4) ^ Claim(s) 1J5 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) D Claim(s) is/are allowed. 

6) E3 Claim(s) 1-5 is/are rejected. 

7) D Claim(s) is/are objected to. 

8) Q Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) D The specification is objected to by the Examiner. 

1 0)D The drawing(s) filed on is/are: a)D accepted or b)D objected to by the Examiner. 

Applicant may not request that any objection to the drawing(s) be held in abeyance. See 37 CFR 1 .85(a). 

Replacement drawing sheet(s) including the correction is required if the drawing(s) is objected to. See 37 CFR 1.121(d). 
1 1 )□ The oath or declaration is objected to by the Examiner. Note the attached Office Action or form PTO-1 52. 

Priority under 35 U.S.C. § 119 

12)£3 Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 1 19(a)-(d) or (f). 
bM All b)Q Some * c)D None of: 

1 .[2 Certified copies of the priority documents have been received. 

2. D Certified copies of the priority documents have been received in Application No. . 

3. Q Copies of the certified copies of the priority documents have been received in this National Stage 

application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 
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DETAILED ACTION 

Claims 1-5 are pending. 



Priority 

A claim for foreign priority has been made. Receipt is acknowledged of papers 
submitted under 35 U.S.C. 119(a)-(d), which papers have been placed of record in the 
file. The effective filing date for subject matter in the application is 22 March 2000. 



Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described 
as set forth in section 102 of this title, if the differences between the subject matter sought to 
be patented and the prior art are such that the subject matter as a whole would have been 
obvious at the time the invention was made to a person having ordinary skill in the art to 
which said subject matter pertains. Patentability shall not be negatived by the manner in 
which the invention was made. 



Claims 1-5 are rejected under 35 U.S.C. 103(a) as being unpatentable over Thackston 
(U.S. Patent Number 6,295,513, hereinafter "Thackston") in view of Saucedo et al. (U.S. 
Patent Number 5,754,738, hereinafter "Saucedo"). 



In referring to claim 1, Thackston discloses a network-based system for the 
manufacture of parts with a virtual collaborative environment for design, development, 
and fabricator selection. Thackston shows substantial features of the claimed invention, 
including: 

• Figure data storage means for storing figure data on a whole including an object 
of retrieval and for transmitting the figure data to the client in response to an 
instruction from the client: 

"It is another object of the present invention to provide such a network-based 
system whereby a central server maintains engineering data, such as design 
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documents and three dimensional model data, in a common, neutral format, 
which is accessible by authorized team members through a graphical user 
interface that is substantially platform independent to reduce or eliminate the 
necessity for specialized hardware and software. " (Thackston, col. 3, line 64 - 
col. 4, line 4) 

• Parts information storage means for storing parts information: 
Thackston, Fig. 2 shows database 210, where the parts information is stored 

• Figure information storage means for storing figure information including 
coordinate data with respect to the figure data: 

Thackston, Fig. 2 shows database 210, where the parts information is stored; a 
system that stores CAD model data inherently implies coordinate data 

• The client comprises a general-purpose web browser for showing the parts 
information and the figure data: 

"Prime contractor user systems 220 may comprise computers running standard 
operating systems and supporting "browser" technologies for accessing and 
displaying data over a common network, such as personal computers with 
Windows NT™ and Microsoft Internet Explorer ™ 5.0 or Netscape 
Communicator ™ 4.06, an Apple Macintosh™ running MOSAIC™ web browser 
software, a Sun SPARCstation ™ running UNIX and Netscape Communicator ™, 
and a Silicon Graphics ™ UNIX-based workstation such as the SGI Octane ™ 
running Netscape Communicator™. " (Thackston, col. 9, lines 53-62) 
However, Thackston does not discuss the display of the parts in great detail. 
Thackston does not explicitly show linking the parts information and the figure 
information to each other bidirectionally or showing the parts list and figure information 
simultaneously. Nonetheless this feature is well known in the art and would have been an 
obvious implementation of the system disclosed by Thackston as evidenced by Saucedo. 

In analogous art, Saucedo discloses a computerized prototyping system employing 
virtual system design environment. Saucedo shows linking the parts information and the 
figure information to each other bidirectionally or showing the parts list and figure 
information simultaneously: Saucedo, Fig. 25 is an illustration shown the example of an 
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interface of the design browser; The model, component files (parts), and a hierarchical 
graph (of how the parts are linked) are displayed simultaneously. 

Given these teachings, a person of ordinary skill in the art would have readily 
recognized the desirability and advantages of implementing the system of Thackston so 
as to link the parts information and the figure information to each other bidirectionally 
and show the parts list with the figure information simultaneously, such as taught by 
Saucedo, in order to provide a view of the overall system while a specific part is edited. 

In referring to claim 2, Thackston in view of Saucedo shows, 

• The mark-up language is Extensible Mark-up Language (XML): 

'In one embodiment, prime contractor user system 220 comprises a personal 
computer or workstation running a standard operating system such as Windows 
NT, and using a standard browser such as Microsoft Internet Explorer ™ 5.0 
capable of interpreting HTML 4.0, XML, VRML, and running Java ™ applets" 
(Thackston, col. 10, line 5-10) 

In referring to claim 3, Thackston in view of Saucedo shows, 

• The figure data are image data, which do not have attribute of coordinates: 
Thackston, Fig. 12 shows that some of the figure data can comprise drawing 
symbols 1206, which do not have coordinate data 

In referring to claim 4, Thackston in view of Saucedo shows, 

• When a retriever selects one of the objects of retrieval which are shown on the 
general-purpose web browser, the one changes visually on the general-purpose 
web browser: 

"The graphics capability allows a prime contractor and prospective fabricator to 
view the three-dimensional part design, including the execution of various 
manipulations, such as virtual rotations and translations, pan, zoom and 'fly 
throughs. "' (Thackston, col. 5, line 64 - col. 6, line 1) 
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In referring to claim 5, Thackston in view of Saucedo shows, 

• External output means for allowing a retriever to take out a result of the retrieval 
and to make use of the result: 

"Stored standard contracts data module 696 may comprise a series of contract 
"templates" for prime contractors and suppliers to use as a starting point for 
creating an agreement. For example, in one embodiment there is a standard form 
agreement for a fabricator to produce a quantity of prototypes of a design within 
some time-frame. " (Thackston, col. 13, line 11-16) 



Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Scott M. Klinger whose telephone number is (703) 305- 
8285. The examiner can normally be reached on M-F 7:00am - 3:30pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Glenn Burgess can be reached on (703) 305-4792. The fax phone number for 
the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. Status 
information for unpublished applications is available through Private PAIR only. For 
more information about the PAIR system, see http://pair-direct.uspto.gov. Should you 
have questions on access to the Private PAIR system, contact the Electronic Business 
Center (EBC) at 866-217-9197 (toll-free). 



Conclusion 



Scott M. Klinger 
Examiner 
Art Unit 2153 



smk 




^ Gmm B. BURGAS ' 
SUPERVISORY PATENT EXAMINER 
TECHNOLOGY CENTER 2100 
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[37] ABSTRACT 

An improved database management system (DBMS) 
stores, retrieves and manipulates directed graph data 
•tinctures m a relational database. Each directed graph 
data structure contains one or more records of data 
which are nrtenxmnected by pointers. Data is stored in 
the database in the form of two dimemk*uJ tables, also 
known as flat fifes. The improved DBMS defines a 
schema for each table m the database. The schema de- 
fines the name and data type of each column in a data- 
base table. In tables used to store directed graph data 
structures, at least one <x>lunm will be defined as ha vmg 
a reference data rype. No»<mp<y en tries in that cotmnn 
arepoim^torowsmaspeonedtaMe. Directed graph 
data structures are stored in specified tables by storing 
each record of the directed graph in a distinct row of 
one of the specified tables, with references correspond- 
ing to mterocmiections between records being stored in 
reference data type column* Portions of a directed 
graph are retrieved from the specified table, in accor- 
dance with a single specified Query and then the query 
is automatically e xp a nde d by also retrieving additional 
portions of the tables winch are refereu^ by the previ- 
ously retrieved portions, thereby performing a transi- 
tive closure. The retrieved data is stored in a buffer as a 
hist of rows, and then communicated to an application 
process. An interlace program converts the list of rows 
stored in the buffer into a directed graph data structure. 
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FIGURE 8 
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1 2 

database is shown in FIG. t This set of data 100, which 
RELATIONAL DATABASE MANAGEMENT denotes a act of automobile parts and also denotes 

SYSTEM AND METHOD FOR STORING, which parte are components of other parts, is herein 

RETRIEVING AND MODIFYING DIRECTED called a "directed graph". The data structures conven- 
GRAFH DATA STRUCTURES 5 tkmaOy used to store such sets of data in computers are 

called "directed graph data structures**. Tne reason that 
The present invention relates generally to computer a directed graph is "difficult" to handle with a cosrven- 
database systcnv and particnlar^ tional database system is that while thb data can be 

storage methods and systems for storing and retrieving stored in and retrieved from a conventional database 
directed graph date structures. 10 table, it is awkward to do so. 

FIG 2 contains a typical prior art table 111 (herein 
BACKGROUND OF THE INVENTION crfW ^ cootonaPtett table) that would be used by a 

A database tnanagexnent system (DBMS) is computer prior art database nsanagen^ system to store tl» di- 
software that stores data and fsrovife software rontmcs rected graph shown in FIG. L FIG. 2 also shows a 
JbrmanirHilatmg the stc^ data. ^ 15 second table 120 (herein called the Parts table) which 

directly (Le^ by human usersX as a component of an- contains cost data for automobile parts. By using the 
other software package, or to provide service to an- two tables 110 and 120 together, one can determine the 
other software package. relative costs of maniifacturing various portions of an 

A database is a collection of data which is stored and au t o mo bil e 
managed as a unit by a DBMS. A M reUtiona] database*' 20 While tabte 110 m ITO. 2 contains aBtte 
is a database which contains tables that are used to store to reconstruct the directed graph of FK3. 1, it is very 
sets of data and to specify relationships between the awkward for a prior art database manageme^ 
different sets of data stored in the database Relational utilize data which is organized m this mshion. For ex- 
databases and database management systems are widely ample, consider the steps which would need to be per- 
used in the prior art Therefore tins document wiD de- 25 formed by the prior art DBMS to generate a directed 
scribe prior art database systems only to the extent graph representing the set of sB components of the 
necessary to point out the differences between such engine. To do mis, we would first have to examine aD 
prior art systems and the present invention. the records with a partName of ENGINE to generate a 

Typically, databases are used to store sets of related first hst of engine parts. Then we would have to exam- 
data. For example, a database may be used to store aD 30 ine aD the records for the parts identified an tins first 
the seat reservations made by the customers of an air- search (Le., with partName equal to CAM SHAFT or 
hue, plus information about the airplane (es>, tenting WATER JACKET OR CYLINDER t etc.). In a real 
chart information), information about the customers life example, we would then have to fismmr aD the 
(e^, address, credit card used to purchase tickets, and record s for the parts identified m the second search, and 
travel agent), and so on. This is an example of a database 35 soon. 

which is weD suited for a prior art relational database fa ternu of search commands using SQU 
management system. standard language for querying datab a ses , a separate 

The reason that the siriine seat reservation database is query would be r e q u i red for retrieving each set of sub- 
easy to use with prior art database technology it that the parts. As wiD be explained m more detail below, to 
data is easily organized as a set of flat records, in the 40 regenerate the portion of the directed graph corre- 
fonn of a few tables: one for seat reservations, one for srjooding to ENGINE, one would have to perform 
customer information, and so on* bteraDy dozens of queries. TABLE 1 lists the fifty-four 

An example of s set of data that b "difficult" to effi- SQL queries which would be rajmred to regenerate the 
cicntfy store and manipulate in a prior art relational entire directed graph for AUTOMOBILE: 

TABLE 1 

PRIOR ART QUERIES FOR RETRIEVING DIRECTED GRAPH 



1) SELECT • FROM Cott^MPtm WHERE PARTNAME - "AUTOMOBILE" 

2) SELECT * FROM CottaatPvti WHERE PARTNAME * "BODY" 

3) . SELECT * FROM CoctHMPam WHERE PARTNAME - "FRAME" 

4) SELECT • FROM Ol^MrfcHi WHERE PARTNAME - "POWER TRAIN" 
3) SELECT • FROM CwtaiotPwti WHERE PARTNAME ** "DASH BOARD" 
t) SELECT • FROM CcatnPvts WHERE PARTNAME - "SEATS" 

7) SELECT » FROM ColwwPfcrti WHERE PARTNAME - "SHELL" 

1) SELECT * FROM OaaUnPam WHERE PARTNAME »- ""WINDSHIELD** 

» SELECT • FROM CfT^Pam WHERE PARTNAME - "DIFFERENTIAL" 

10) SELECT * FROM CoataiatPfcrts WHERE PARTNAME — "DRIVE SHAFT* 

11) SELECT • FROM CMMrtt WHERE PARTNAME - "ENOINB" 

12) SELECT • FROM OmmmP u U WHERE PARTNAME - TRANS MI SSIO N " 

13) SELECT • FROM CoabrimPvti WHERE PARTNAME m "CAM SHAFT" 
W) SELECT • FROM CimlMk m PmiU WHERE PARTNAME • *CTUNDER 1 " 

15) SELECT * FROM GoaaSMPirtt WHERE PARTNAME «• ^CYLINDER T* 

1 6) SELECT • FROM QabWMi WHERE PARTNAME * ^CYLINDER V 

1 7) SELECT • FROM CmtMKPm WHERE PARTNAME - "CYLINDER 4" 
U) SELECT • FROM Ctm t ^T m WHERE PARTNAME - "CYLINDER V 

19) SELECT • FROM OattriatPtiti WHERE PARTNAME * "CYLINDER i" 

20) SELECT • FROM Co «ttl » i P *itt WHERE PARTNAME - "CYLINDER 7" 

21) SELECT • FROM QmCmmPm WHERE PARTNAME » "CYLINDER S" 

22) SELECT * FROM CoacaasPcm WHERE PARTNAME -» "WATER JACKET* 

23) SELECT • FROM Coa ui i m Ptrti WHERE PARTNAME - T1STON 1" 

24) SELECT * FROM OoabamPutB WHERE PARTNAME ~ "PISTON 2" 

25) SELECT • FROM CarttmPtm WHERE PARTNAME - "PISTON r 

26) SELECT * FROM GoRfetfatPara WHERE PARTNAME m "PISTON 4" 
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TABLE 1 -continued 

PftlQlt ART QUERIES FOR RETRIEVING DIRECTED GRAPH 



27) SELECT • FROM 
2f> SELECT * PROM 
29) SELECT * FROM 
W) SELECT* FROM 
SI) SELECT* FROM 
32) SELECT • FROM 
S3) SELECT * FROM 
M) SELECT * FROM 
15) SELECT* FROM 
3f) SELECT * FROM 
37) SELECT * FROM 
30 SELECT* FROM 

39) SELECT * FROM 

40) SELECT* FROM 

41) SELECT* FROM 

42) SELECT * FROM 

43) SELECT* FROM 

44) SELECT * FROM 

45) SELECT* FROM 

46) SELECT * FROM 

47) SELECT* FROM 
4t) SELECT * FROM 

49) SELECT* FROM 

50) SELECT • FROM 

31) SELECT* FROM 

32) SELECT* FROM 

53) SELECT * FROM 

54) SELECT * FROM 



WHERE PARTNAME ■ 
WHERE PARTNAME > 
WHERE PARTNAME > 
WHERE PARTNAME - 
WHERE PARTNAME « 
WHERE PARTNAME - 
WHERE PARTNAME • 
WHERE PARTNAME * 
WHERE PARTNAME < 
WHERE PARTNAME - 
WHERE PARTNAME • 
WHERE PARTNAME > 
WHERE PARTNAME • 
WHERE PARTNAME « 
WHERE PARTNAME * 
WHERE PARTNAME < 
WHERE PARTNAME • 
WHERE PARTNAME > 
WHERE PARTNAME ■ 
WHERE PARTNAME < 
WHERE PARTNAME • 
WHERE PARTNAME 
WHERE PARTNAME 
WHERE PARTNAME 
WHERE PARTNAME 
WHERE PARTNAME 
WHERE PARTNAME 
WHERE PARTNAME 



.-PISTON 5" 
. -PISTON 4T 
r -PISTO N T* 
» "PISTON s~ 
i -SPARK PLUO r 
. -SPARK PLUOr 
.-SPARK PLUO r 
. -SPARKPLUG 4~ 
. -SPARKPLUG 5" 
- -SPARK PLUO 67 
. -SPARK PLUO V 
--SPARK PLUG r 
. -EXHAUST VALVE 1~ 
■ -EXHAUST VALVE r 
. -EXHAUST VALVE T 
. "EXHAUST VALVE 4" 

• TEXHAUST VALVE 5" 

• -EXHAUST VALVE fT 

■ -EXHAUST VALVE T* 

- TXHAUST VALVE 1 M 

• INTAKE VALVE t- 

■ INTAKE VALVE T 

- "INTAKE VALVE T 
.-INTAKE VALVE r 

- INTAKE VALVE 5" 
m INTAKE VALVE 6** 

- -INTAKE VALVE T 

- -INTAKE VALVE V 



By wsy of comparison, the present mvention allows a ment system. From another perspective, the primary 
person or p io gram to retrieve an entire subtree (or even goal of the present invention is to modify conventional 
a pruned subtree) of a directed graph using a single 30 relational database management systems so as to effi- 
query. The single query needed to retrieve the entire eiently and intelligently handle data which is logically 
dir ec te d graph in the preferred embodiment of the pro- organized as a directed graph, 
ent invention ir An important property of the present invention that is 

not provided by prior art relational database manage- 
"35 ment systems is ^transitive closure". Transitive closure 



SE ^^Sl23Sf*) meawtheahuitytofoltowth^ 

where PAKTNAME - -AUTOMOBILE- data structure and to process an entire or specified por- 

tion of a tree or directed graph as single entity. Data- 

M . « ^. « ■ . . „ . # base management systems which include the features of 

Thesmg>QuerywtachwouMie^ =S^mS^mOtin transitive closures, 

the directed graph correspond^ 40 ^eas^Wrd^ 

1 do not. 



SE ^r^SSSa^) SUMMARY OF THE INVENTION 

where PARTNAME - "ENGINE" 4S ^ gummary, the present inventkm is an improved 

dtla bt f r -f**Q~*u*r*t *y*tm (DBM^ which can stores 
Trees and other directed graph data structures are retrieve and manipulate directed graph data structures 
nry used in scientific and engineering appbea- in a relational database. Each directed graph data struc- 



1 to represent and store data. Because of ttehmita- ture comprises one or more records of data which are 

1 m the prior art, these types of scientific and cngi- SO mtercosmected by i>ointers> Dam fa stored m 

neering data are typically not stored using database base in the form of two di mrr m onal tables, also known 

mtvo-n^ «y«temi. Am a resnh. all of the well deve*- as flat files or base tables. 

oped tools asrwi Uf ri with database ~— ays* The improved DBMS defines a schema for each base 

temsaregeneraUyr** available to to table in the d at s h as r The schema defines the name and 

and engineering data. Instead* such dam b typicaOy 55 data type of each column in a database table, rotables 

ttjtrrd f~« mMityin lMtiMl using a wide variety of special used to store directed graph data structure^ at least one 

software programs. These programs vary widely m column of the table wffl be defined as hav ing , a reference 

their of oprratiffs how they represent data data type, which means that non-empty entries in that 

internally, and so on. Unlike relational database man- column contain ••references" to other rows in the same 
tsr «~« systems, the progr am s each have a different to or other tables in the database. A *Yefcjcnce** is a datum 

fa^ffinrrr^mnAmm^timfctAhewMAhyiMfy* (stored m a reference column of a table) which matches 

small market niche. the primary key a particular row m^ 

Tteprinmygc>eloftbepr m the database, 

scientific and ~fj~~**g data, winch m normally Directed graph dam structures are 
stored in the form of tree data structures or directed 65 database tables by storing each record of thedirected 

graph data structures m operating system file* fix., files graph ma distinct row of a specif 

directly accessed by application programs), to be easDy tions between the directed graph's records are repre- 

rtorrd smf T™"T»i^«d « • «rftinnal database manage- ' aented or denoted by references stored in reference 
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columns, i.e., columns denoted in the tabled schema as skilh necessary to raplemeiitapplic^^ 
being a reference data type column. Portions of a <&• ified application dorjuin, and are alio akilled in the use 
rected graph are retrieved from base tables, m response of prior art RDBMS products such as IBM's DB2, 
to a query, by retrieving a portion of a first specified Oracle's Oracle, and Ingres (a trademark of Ingres Inc.). 
base table in accordance with the specified query and 5 Application programmers of ordinary skill in the art are 
then expanding the retrieved data by also retrieving also skilled users of programming languages, such as C, 
acVirtkaul portions of base tables wtiicb are referenced the MAINSAIL programming language, and ADA, 
by the portions of the first specified table already re- and can const r uct p rogra mmi ng language interfaces 
trieved in accordance with the query. which enable an application to send queries to a prior 

In the pre fer red embodiment, the portions of a table 10 art relational DBMS system and to receive data and 
retrieved in r e sp o ns e to a query are stored in a buffer other r e spon ses generated by the prior art DBMS, 
and then transmitted or ccaminiikated to an application BASE TABLE — A table that corresponds to data 
process (Le^ to whomever scat the query to the physically stored in a permanent storage medium, as 
DBMS). If the retrieved rows from die database include distinct from a. derived tabk that it defmed by a query 
non-empty reference values, those reference values are 15 used to retrieve data from a base table, 
automatically converted by the DBMS into pointers C— A programming langu a ge , often used to write 
which point to other retrieved rows that are stored in cs*gmeering application progr ams . See for example, B. 
the buffer. The application rjixcess indudes an mterrsce Kermghan and D. Ritchie, The C Programming Lan* 
program for co n ver tin g the retrieved portions of the guage", 2nd Edition, Prentice HaB, New Jersey, 19SS. 
srxcifVd table into a directed s^aph dau structure. 20 CYCLE— In the contest of structured data such as 

Updates or tnodifications of directed graph data directed graph data structur e s, a cycle is a closed loop 
structures are handled in much the same way as storing consisting of a series of references from one co mp o nent 
a directed graph in the first place. The modified per- back to itself. For example, if the interstate highway 
tions of the directed graph are converted into a set of system were r e p re sent ed m a database, where each 
rows in accordance with the specified schema for the 23 highway was a row that co ntains references to each 
target table or tables (Le., die tablets) m winch the di- other row (highway) for which Acre is an exit, there 
rected graph is to be stored). Each rcssuung row of data would be many cycles, because it is possible to start on 
ktliens^ to niodify or update c^ one highway, emit to another, and eventually esh back 

of the target tabk(s). onto the origina l highway. 

. j i . , _ _ hi i i_u' j.i 30 DATA ITEM — An instance of a particular data type. 

BRIEF DESCRIPTION OF THE DRAWINGS For example, the number I it an mstance of the data 

Additional objects and features of the invention will type INTEGER, 
be more readily apparent from the following detailed DATA TYPE— A name for a set of possible values 
description and appended claims when taken in con- that may be r epre sent ed in a computer's memory, along 
junction with the drawings, in which: 35 with a set of operations on those values. For eiamplr, 

FIO. 1 depicts an example of a directed graph. the data type INTEGER aOows for the representation 

FIG. 2 depicts two tables for storing data cone* of positive counting numbers (1,2,3*-.), negative mm> 
spondmg to the directed graph shown in FIG. L bers (—1,-2,— 3^-X and aero (0), and provides for 

FIG. 3 is a Nock diagram of a database management arithmetic operations such as addition and multrpbca- 
system in accordance with the present invention. 40 tson. Each DBMS product supports a predefined set of 

FIG. 4 illustrates a directed graph data structure. datatypes. 

FIG. 5 depicts the schema for a database table used to DATABASE — A collection of related mfonnaoon, 
stored directed graph data structures. or data. Many da t a b a ses are abstract representation of 

FIG. 4 depicts an example of a database table used to information pertin e n t to an enterprise, such as the de- 
stored directed graph data s tr uc tur e s , 45 sign of mtegrated circuits. 

FIG. 7 depicts the data structure for a hst of rows DATABASE MANAGEMENT SYSTEM 
retrieved from a database using an VTtr rvtr* query. (DBMS)— A component of a computer system that 

FIG. t depicts a hash table used during data retrieval provides support for the storage and management of 



DESCRIPTION OF THE PREFERRED 
EMBODIMENT 



SO DERIVED TABLE — A table that it defined by the 



results of a query that letrieves data. 
DIRECTED GRAPH DATA STRUCTURE— A 
Referring to FIG. 3, there is shown a multiuser data- data structure that models arbitrary relationships 



t system (DBMS) 200, drawn so as to among data objects. Directed graph data structures 
:lhe portions of the DBMS which are partico- 55 include, for example, trees, linked lists, and cyclical 
larfy relevant to the present invention. Before discuss- graph structures (structures with cycles). Directed 
ing this Figure m detail, the foltowmg glossary of tenns graph data structures are defmed and d^scossed in Aho, 
fc provided. Data Stnsctures and Algorithms, Addjson-Wesicy, 1983 

™ (PP- 19S-199). 

GLOSSARY Co ENGINEERING APrUCATTONS-Apc4ica- 

AFPLICATION— A computer program that solves tions, such as computer-sided design (CADX computer- 
some particular problem. Applications may use a aided rnanufiactaring (CAM), and cosnpoter-aided soft- 
DBMS to store and soasapulate information relevant to ware engineering (CASE), that must retrieve, mampu- 
such application. late, and store structured data that model objects of 

APPLICATION PROGRAMMER— The person or 65 much greater complexity than typically found in busi- 
persons who write the source code for an application, ness applications. 

such as a computer aided design program. Application FOREIGN KEY — A foreign hey in a table Tl is a 
programmers of ordinary skill in the art possess the hst of one or more columns in table Tl that correspond 
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to the primary key columns of a base tabk T2. (Table RETRIEVAL QUERY— Any query that tpccifct 
TI and T2 may or may not be distinct) Thus, the Tor- that data be retrieved (passed from the DBMS to an 
ago key colnma values in a particular row of Tl togi- applica ti on ) . 

crtyrtertothcioworTlwboHfximMrykcy column ROW-The bst of related column value, a a table 
varus matches such foreign key column values. * corresponding to a particular primary toy value. 
^-Anordert^c^ofreroormore<taU SOffiMA-A *^J**^«?T?^ 
items, possibly contaming some duplicate values. represented by a database. l^jaMririy 

mi^Awui^^maptdMyZt. ttaal database* a o«*crii*<» of ttetabtotlsUniakeup 

PRIMARY KEY — Associated with each b«e table the iteabaae^dwlmg the table J^J* 8 "*^ 
in a relational datable * a. ordered fat of column. «> !^ ^ «^ ^^^J^^JS^I 
whose van*, uniquely identify a particular row of the ^ h ^LZ^SS^l 

table. This list arootmecmt^lbKpnamtybyai DBMS, or a user to interpret the contents of the data- 
the table. More pBrtiralarly, the primary k/y of an indn ^^f- . - „ n ii.„.;r- *r „^ „ 

vidual row of the table consists of the vriues of the tmoriered ?*£^*J°™~ ■ ore 

nrimarv key columns for that sow. Speculation of the 15 unique data hems, none of which can be null. 
yM—ry acy ""'»»" " «y" " n "■■ r " CTRlirrnntED DATA— Data that model the com- 



pkx structure of real-world objects and events, mcfud 
fag fm pwrf) mrfriplc Kaha from one component of 



identify that parrimarr row. 
PROGRAM — See appBcntion. 



that tells the DBMS to perform a desired action. Typi- 

calactioiis include the retrieval of data from the data- d ^J??!^_ OUERY LANGUAGE 

^^eh^tothed-a-oredmmed^ ^S^y^^^ 1 ^^ 

QUERY LANGUAGE A computer 25 ^2*^?^ aSsT^S^ 

cjiuf e asin g data retrieval questions and aaodsfics&on " -» ■ ^ ; lmmAm .,,,_„„ g f,,i 

nT.ratirurT . 4.«.h.~ Th* oiiflv ltHotiAiK define* artetwoB of this ttandard to include more powerful 

mriwimg the syntax and toe actions or me a ning asaoa- i w ^~l^-ai rwtmnmtim far Ca»,nt>ti«»«»uni 

^r^rfn ^ L^T ^m^fff- -mr- tured" in the contest of SQL is completely 
RECORD— A record is a memory resuent aggre- .>,,,,_ of the same word m "structured data' 

gate data type W^ *^ j'?*ZS < n^ T"ABLE — Each table is described by the 
ronments. Each such programming environment pro- . . enmnst* <rf a net of "rows", each of which 

vides a way to declare a description for each type of 35 tS£ 
i^ta^byaaanulcaliooCmcIo^ ^^TleVeV REOORD— The starting point of a 

Woftteam^dmaty^^jvUmre- d ^^ da ^^ Hfcpr ^ uTT^ 
cord), a way to allocate new m tta n m of each record caikm*% maaory 

type, and. often, a way to dispose of (recycle) records TOP-LEVEL ROW— The starting point of a <ti- 
when no kmger needed by the apphcatkm. «° 

REFERENCE — REFERENCE is a database col- 
umn data type which m an extension of the concept of 

foreign key. Column that are declared in the schema to DATABASE MANAGEMENT SYSTEM 

be of type REFERENCE are used to refer to individual ^ yj^ dataDttc ^^^^t system (DBMS) 20ft 
rows by m a t c hin g foreign key values to primary key thown m FIO. 5 b coupled to a number of application 
values. The REFERENCE data type is used in the (^ccsses 202-204, htvehufter called applications. The 
database representation of directed graph dau struc- DBMS 200 stores, retrieves and updates mformation m 
tores. In a table having a reference column, each noo- a dfrtafaaae 10< on behalf of the applications One of the 
empty reference in the table matches the primary key ^ pnniixy benefits of using a DBMS 200 is that it relieves 
vafoe of a row ma specified tabfe ^ppfr^t™* p ro gramm ers from having to deal with 

ences dhTer from foreign keys m several ways that are | | ate storage and retrieval, and instead allows appbea- 
cxplain in detail below. Moat sn ip ortandy. a i^erencei* tion proajainxners to coo 

essentially a set of bits which match the primary key of kms for which a specified apphcation program is being 
a row m abase table. Each reference 35 developed. Anc4her benefit oft^smg a DBMS 2W^ 

a single inference cohmm. even if the corresponding h provides a iDfchauri^ 

primary key occupies two or tions to share the information in a shared datab as e 206. 



reeled graph data structure as represented mintt 



Physically, the data m tl»e database k typsc^ 
RELATION — A data table of values, such data table partially in high-speed irokm acce^ 



an open-ended and unctfdered collection of rows, & and parnaDy on disk drives. A storage 
row consisting of an ordered and & .wbtyitem 2S)t managar^ 



204, and typically indwfr* [ 

RELATIONAL DBMS (RDBMS)— A DBM S that features such as software for disk caching and for inctex- 

allowi an application to define and operate on a data- ing on column values. A "b-tree~ or ~b+txt*r physical 
base using the abs tr action s of the standard relational 65 storage technique is often used by commercial DBMS, 

anodes which frees tl* a« Since storage m a uagnnent is not related to the present 

base storage comidersiioss. In particular, data are rep- mvemkm, aiid b wefl w 

Dted using relations (tables). it is not discussed any further f 
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In the preferred embodiment, each application pro- purpose of the application interface 232 h firstly to 

ocas 202, 2(MwiUreskte on a separate computer » each ammunicate queries from the application program to 

which is coupled to a host computer or network server the DBMS process 210 (see software module 234) and 

which runs the tMf^f tr management system process trpppdr y tfECtrmp nimcy*? tr * nMP ' t d*ia in both dtrec- 

210. The DBMS process 210 includes a separate appb- 5 tkms between the application program 230 and the 

cation task 212-214 for each application that is cur- DBMS process 210. In the context of the present inven- 

Tmtfy utmg thf dafrHtr To fwrdmatr iir"*™""*—- boo, the sofrware 236 for transmitting data between the 

tkms with multiple applications and to aDow a single applic a tion program 230 and the DBMS process 210 is 

ccsnputertonmnnih^ap called a data translator or converter because it coavertt 

process no uKOudes a miihhaskm^ 10 directed 1 graph data structures 240 from the application 

220. In other words, the computer on which the DBMS program 230 into a farm suitable for trwmmttal to the 

is running includes muhitasking np— »»mg gystem soft- DBMS process 210, and abo converts data retrieved 

ware for handling multiple tasks or execution threads. from the database 206 into directed graph data struc- 

As wiD be understood by those skiDedm tores for use by the application program 230. 

are many poanMe system cccifiguntions. aD of winch 15 More specifically, data retrieved from the database 

areec^irvalentforthepurpc^ 206miespc^toaq«ery fromapplicat^ 

For example, in other embodiments it would possible nutted to the application process 202 mtl* farm of a list 

for both the DBMS and the application programs to all 2« ofoi* or snore tows of ictrieved data. The list 244 

be running on a single computer, or for the DBMS and contains portions of one or more of the base tables 

sonie of the application rjrogranis to be r^ 20 stored m the database 206. In other words, each row in 

host computer (eg., a mai nfr ame or high performance the hst 244 coinprises a selected row, or a portion of a 

niinicompuler) with other application programs run- selected row from a base table. Furthermore, each row 

ning in separate computers that are coupled to the host in the list 244 may come from a distinct base table, 

computer by a communications network. The fist of rows 244 retrieved from the database 206 

The ********** sent by application p roces ses to the 25 ■ temporarily stored in a buffer 241 m the application 

DBMS 200 are typically called queries. Furthermore, task 212 of the DBMS process, and then the contents of 

many database systems use an industry that buffer are transmitted to buffer 242 in the applies- 

standard query language, called SQL (Structured tioo interface 232 The data translator sofrware 236 

Query Language), which defines the syntax and inter- converts the retrieved data stored m the buffer 242 into 
pretariooof the emeries which cam be used by app&»- 30 a directed graph datt structure 

tkms to store, retrieve and nianipulatedaU ma database tion program 230. In other words, each row of the list 

system. For the purposes of this dVscripboe, it is as- 244 in the buffer is converted into a record with a data 

sumed that queries sent by applications to the DBMS structure oompatftk with the arjphcatioo program 230. 

200 in the preferred embodiment of the present invca- When directed graph data structures 240 are sent by 

tion conform to SQL, with a few exceptions that are 35 the application program 230 to the DBMS process 210 

described m detail below. for storage mthe database 204, the daU translator 234 in 

Each application task 212-214 m the DBMS process the application internee 232 converts that data into a 

210 uses a shared set of software for handling queries list of row* 246, and stores that list m buffer 242. Each 

from applications. The three primary software modules row m the hst 244 has an asso ciated row number. The 
or sets of sofrware which are modified by the present 40 pointers m each record (U-. pointer fields which point 

invention are the software 222 for defining database to other records) that ia stored as a row m hst 244 are 

tables and their associated scmemas, the software 224 for converted into row nunmeii. Furthermore^ each row or 

interpreting queries sent by application programs, and record m list 244 has a set of cc4un*n* that are a subset 

the sofrware 224 for handling data storage, retrieval and of the cohnnnsof a base table that is stored m the deta- 

inodhVation. 45 base 206. After the records of the directed graph have 

The data stored in the database 206 » organized as a been converted into a list of records stored in buffer 

set of base tables. Each base table 227 consists of an 242, the contents of the buffer 242 are transmitted to the 

array of data organized in columns and rows. For each DBMS process 210 for storage in one or more target 

base table 227 there is a ecoeapesdmg schema 220, b& title*. In the rx^coawmc^rt the columns 
which defines the data type associated which each cd- 50 each record of the list 246 match the dau types of col- 

umn in the table 227. For iastance, the first column of umas in a target base tabic the records m the hst 246 

the table 110 (shown in FIG. 2) has a data type of "char- can be directly copied into the target base table, 

scterstring^ and the second cofanm also h^ The data structure for storing the retrieved list of 

of "Character string". The second oolumn of table 120 rows 244 and the hst of records to be stored 246 is 

shown m FIG. 2 has a data type of "decimal". Base 55 described below with r e fe renc e to FIG. 7. 

taMa and schemas wffl be ckacribed in more detail DIRECTED GRAPH DATA STRUCTURE 

As is standard in prior art DBMS% each base table The present invention is particularly suited ^ ««™ 
227 also lias one or more moices 229 whk& are special- conjunction with engmeering ap p licati on programs, 
ized data structures for quickly locating any tj m 'r f f n * 60 such as computer-aided design (CAD) programs, corn- 
row in a base table. As wifl be discussed below, every pvterHUdcd inanuCacturing (CAM), and computer-aided 
base table 227 has a priinary key and an sate for that sofrware engineering (CASE), and other programs 
primary key. which must store, retrieve, and snanipnlatr stiuctured 

. ... , data that model objects of much greater cui up st ii t y 

APPLICATION INTERFACE. « ^ typically found ta bc*inm apr*calkras. 

In the preferred embodiment, each application pro- Referring to FIG. 4, there is shown a directed graph 

cess 202-204 includes an application program 230 and data structure 330, similar to FIG. 1, but explicitly 

an application interface 232, as shown in FIG. 3. The showing the pointers between records m the datt stroc- 
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cure sb one particular programming en viromneDt Each continued 

record 331-346 of the directed graph d*U structure 330 mnm ^w^ Z 

m this example include! a name field 350, followed a £^^^5?^ 

decxma) number field 351 for storing cost data, followed reference (Pvti) SET c 

by a set 352 of pointers herein labelled CONTAIN- 5 primary key p«iN—e ) 

SPARTS111, CONTAINSPARTSP1 and so on. For 

eismplr. the top-level record 332 of the daU structure Firrwrkm of this command would generate the 

330 has a name field with a value of AUTOMOBILE, f^w- 41ft shown m FIG . 5 and an empty table 400 

and is coupled to records 334. 336 and 333 by a set of having the format of the table shown in FIG. 6. While 

three pointers. Record 334 is coupled, in turn, by four 10 ^ key B this example is based on a single 

pointers to records 340. 342, 344 and 346. Record 340, ^„» n ,_r a* t-M>, « mny application*, the primary 

labelled ENGINE, is coupled by pointers to ten other key wiD be an ordered hst of columns whose values 

records, not shown in this Figure. mnqnery identify a psntkmlar low of the table. 

SCHEMA AND TABLE FOR STORING 1S standard ^^^^^^^J^J^ 
rkrnPi^rsm ntAmfi schema can be snodififfl after their mrnal oenrtmon. 

DIRECTED GRAJ^ ^ ^ ^ colnnsili ^ * ^ to a pre-existing base 
The primary change to the software 222 for defining tmbk: ^ ooinnms can be deleted. For example, it is 
tables and their asso ci a t ed schemas is simply to add one patfMt to add columns with a Reference data type to a 
additional data type to the set of allowed data types preparing base table which does not contain any Ref- 
which can be specified for the columns of a tame, in 30 £^ ^ 0 lunm* 

particular, the present invention adds a new data type preferred yr»™«*«-~»t of the present invention 

herein called the *Tlef erence" data type, for columns of tfe adds three additioiri 

a table which contain references to other rows in either art relational database management systems: ARRAY, 
the same base table or another base table. LIST and SET. in particular, any column of a base 

Referring to FIGS. 5 and 6, there is shown a base 25 tMc ^ ^ have a data type of ARRAY, 

table 400, herein called the •♦parts" table, which is suit- LIST or SET. as well as the other standard data types, 
awe for storing the directed graph dam structure shown such as IKTEGER, STRING, DECIMAL(x,y) and so 



mnO.4.andthescl>ema410forthatbatt on. An ARRAY is simply a conventional array, i 

particular example, the base 400 rfx^jm F 1 °' 6 x the arrays used in FORTRAN and other computer 



has three cohmms: a M partaame" column 402, a costs ** ^^^^ what is unusual about the ARRAY data 

data column 404, and a "cootamsparts" column 406 ^ m ^ cotaaX the present invention is that a 

containing a set (see definition of a "set" in the CHos- odmnn of a base table can be defined as an array, and 

sary, above) of references. The base table 400 has a mus emch row m the base table wul store an array of 

multiplicity of rows 420, each of which contains a re- data in that particular column. A LIST is an ordered 

lated collectxm of daU Cm this example, tte rfr fl f ^ A » ,-«f , ^fry^ ^^yr^wmmrf^rtirt frmillof 

row ooncerus one "parT of an automobile). nooHmione. A SET is a i mordered collection of non- 

The schema 410 for s table denotes the name of the ^ vmlnefc ^ rehrional database 

table, and then contains a distinct entry 412 for each management systems could only store one data value in 

column of the table 400, each entry defining me name etaama portion of a row. These three iiew data 

and data type of one column in the corresponding base tvzx* — mV ~ k much easier to store the type of data 

table 400. The first item 414 in the schema 410 m FIG. encountered in eiigmeering and scientific type appbea- 



5 is the table's name, which is "Part*". The next hem 
416 m the schema defines the first column 402 of the 

table 41ft, memding the name of the column, Tart- REFERENCE COLUMNS AND POINTERS 

Name", and its data type, which is -character string". The dam stored m a cohimn wim a da^ 

Next, the schema contains a definition 413 of the second m ^j^g, pointers or Terences** to rows m a 

column of the table 404, which stores cost data. As wedged base table. As shown in FIG. 5 above, the 

L^**lfi£_^^ ipecificatioo for a ref erei« cohunn m a tabk's scorns 

mal(9ar. which mdicatca the cost data contains mne w nW of the base table for which the column contains 
digits, two of which are to me right of a de^ references. Thus, aD the r e fe rence s in one reference 

TT* last entry 4^ tte schema 410 mdicatm that oohmm ^ a table may reference rows m Table A" 
^^^^^^^^^^y^^^ whfle ^ fdere nces m another reference cohmm will 
? OOT ? Crrf Ct ^^^^^^l^ a ^^^ Zll 55 reference rows in Table B*\ Table A or B may, or may 
ing the name "CONT AINSP ARTS", wim a data type " not. be the same table as the one containiag the refer- 
of "Reference (Parts)", which means that each value "™ » 

M t^^^^J3^1^^ More generally, references are similar to -foreign 

^I^.^^^^^i^meDBMS • ^ of cotumn values stored in a first table 

To qefhea newbese table m which matches the |»mn^ key vslne of a tow m an* 

provides a CREATE cosnmaiidwInU defines me name twa _ _*l_4v value tforad m a amale 

table. For example, the CREATE command for creat- *? ^ta. Q^tsbuns the reference data column, or in 
k, the t^m FIG * would be: & ^^^^f^^^^^Tv^ 

nqnired to define thai primary key. in other words a 

CHEATE table hu( reference value stored in a tingle cohmm will match the 
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binary bit pattern of a multiple column primary key. Usually, when data from a directed graph b being 
The values stored in Reference columns arc •onetimes inserted krto a database, the columns in each row which 
herein called "pointers'' because primary key values b stored in the intermediate format are the same as, or 
are, logically, pointers to rows m a table. In terms of a subset of tbeccduninsof the target base table m whkh 
DBMS programming ^^pn, each primary key it 5 the directed graph is being stored. However, an update 
cgmvertori during th» ^tim nf t™**m<+i~* y mt^ mmi n^ query can specify an expression defining the value to be 
into a pointer to a particular address in a computer's stored in particular column as a speci fi ed f un c ti o n of 
memory through the use of an index. Thus each non- one or more fields m the directed graph record being 
empty reference value points, directly or indirectly, to a updated. 

particular row in a specified table. HV The fixed format section 456 contains one row 470 for 

every row of data that it being transported. Each row 
410 begins with a "table number**, which references one 
of the table definitions m sccom 454. The remainder of 
The first step in storing a directed graph data struc- the row 470 contains all the columns of the row which 
ture in a database is for the application program 230 to 15 are fixed length data items, Lc, retorting variable 
transmit the directed graph data length strings* lists, arrays and so ocl Each column in 

cation interface 232. Note that when a directed graph b the row 470 which contains variable length data b re- 
being sent by an application for storage in a database, placed by a pointer to an item m section 450 of the 
there must already be one or more base tables 227 m the buffer, at which position b stored the actual data value 
database 204 which have suitable sets of columns for 20 for that column. Furthermore, for each reference col- 
storing thb directed graph. Note that a directed graph mnn, the reference value b replaced by a row number 
may contain a number of diffe re nt types of records, indicating which row m the fixed format data section 
each of which stores different types of data. Typically, 456 b being referenced. 

each type of record in the directed graph wiD be stored Note that by replacing variable length data with fixed 
in a different base table, although other arran ge me n ts 25 format pointers, the rows m section 454 are aO fixed m 
are poss&Je. length. 

If the base tables needed to store the directed graph The variable format section 450 contains variable 
do not yet exist, the application p ro giam 230 must first length strings and other variable length data. Each such 
send instructions a CREATE TABLE command) item 400 stored in thb section 450 b pointed to by a 
to the DBMS 210 so as to define the needed base tables. 30 column entry in one of die rows 470. 
These base tables are called the "target* base tables in Furthermore, when storing data into the buffer for- 
the database. mat shown in FIO. 7, either while retrieving data from 

the database or storing a directed graph for transports- 
Intennediate Data Fonnat for Buffered Data ^ to ^ m*,^ ^ foltowing techniqw b ii^ to 

Referring to FIO. 7, data b trans ported in both direc- 33 avoid storing duplicate copies of rows or records. Re- 
tions between the application p ro g r am and the database fcrring to FIO. 0, for each row stored in the boiler, an 
management system using a '"portable data represents- entry 492 b made in a hash table 490. That entry 492 
tiosT, which b essentially a sctfntocuinenting list of contains a unique row or record identifier (e-*>, the 
rows. FIO. 7 shows the data structure 450 of the trans- primary key for rows retrieved from the database, and 
ported data as stored m the buffer 242 of FIO. 3. Thus 40 the address of records obtained from a directed graph), 
the terms "buffer", "portable data structure*', and **h> a pointer to the corresponding table definition in the 
termedbte data structure" are herein used interchange- table definition section 454 of the buffer, and a pointer 
ably. to the row as stored in the fixed format data section 454 

As shown in FIG. 7, the data stored in the buffer 242 of the buffer. It also contains a link field 494 for setroen- 
hss a header 452, a table definition section 454, a fixed 45 bally accessing all entries in the hash table m the same 
format row storage section 456, and a variable length order that the entries were added to the hash table, 
format data section 450. The header 452 defines the size Before storing each row or record in the buffer 241 or 
of the buffer and die size of each section of the buffer, 242 die application interface or DBMS (depending on 
as well as the number of rows of data stored m the data which direction data b being transported) checks the 
structure. SO hash table 490 to see if there b already an entry 492 m 

The table definition section 454 defines the format of the hash table for that row or record- If so, the row or 
each distinct type of row stored m sections 454 and 457. record has already been stored in buffer 241 or 242 and 
The first item in thb section b a list 459 of all the tables so the row or record b not stored a second time in the 
names for which table definitions follow. Each table buffer. 

definition 440 includes a definition for each column, 33 TWriftjui s^. *r • ti.t t.ki* 

mduding a hst of ocJumn iiamea 44% a h^ of column Vl>datmg a Specified RMoo of a Base Table 

data types 444, and for those col umns which contain In the preferred embodiment, using an extended ver- 
derived data, ei prcsiion s 444 denoting how values m akm of the SQL query language, the mortification 
the columns were derived. The latter field 446 b used queries include an INSERT statement, an UPDATE 
only when retrieving data front the database There b so statement, and a DELETE stairmrnt 
also a primary key defi ni tion 440 denoting the ordered Consider storing the rows m parts Table 400 (shown 
set of columns of the table which form its primary key. in FIO. 4) related to the engine and parts within the 



engine. Using prior art SQL commands rrqiiiirs 43 
queries: 



INSERT INTO Para VALUES ("ENGINE*. 300000, *CA*t SHAFT*. ... ) 
INSERT INTO Para VALUES ("CAM StAFT\ SOOlOQ, """....) 



15 
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INSERT INTO 
INSECT INTO 
INSERT INTO 
INSERT INTO 
INSERT INTO 
INSERT INTO 
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■continued 

VALUES ("WATER JACKET", 500001 —,...) 
VALUES (XYUNDER I*. 2SO00L "PISTON I"....) 
VALUES ("EXHAUST VALVE r\47Ja~\...) 
VALUES CWTA1LE VALVE r\47Ja ~...> 
VALUES CTI5TON 1". ISOCO, —,...) 
VALUES CSPARK PLUO 1", 100, ""....) 



INSERT INTO hfti VALUES ("CYLINDER I". 23000, TISTON t*\ . . 

INSERT INTO Mi VALUES ("EXHAUST VALVE f v 47 JO, "*,...) 

INSERT INTO to* VALUES ("INTAKE VALVE r . «? SK — . . . . ) 

INSERT INTO Hm VALUES CTOTON r\ 150X0, — ... > 

INSERT INTO Pkftt VALUES fSPARK PLUO 1"» SjOO» —*,...) 



Using the schema definition lor Table 400 and the is rected graph, into a specified base table in the* 
INSERT statement provided by the preferred embody The USING ARO portion of the statemenl 
ment of the present mvention, the forty-three rows of wrist portions of the ARG directed graph dau structure 
Table 400 that describe the engine and its subparts are are to be inserted into the database In particular, for 
inserted using the single query: each record REC in the ARO directed graph data 

20 structure whose oorresnondmji bate table is <ta- 
INSERT INTO PARTS USINO ARO 20 53w> and Ibr^W^ istoue 

where ARO refers to a directed graph data structure <U» when applied to RECK the a p plica t ion interface 
argument, supplied by the application program, that inserts into the co lumns sp ecified by <mscrtLsst> of 
represents the engine and its subparts. In other words, the base table specified by <tableName> values of the 
the app^icatknprogira would fir^ 25 fields in REC given by <valuesSpec>. If the optional 

graph data structure called ARO. Then it would exe- < valuesSpec > in the USINO ARO clause is omitted, 
cute the above INSERT query to insert all the engine the fields of die inserted records are assumed to cone- 
data into a frf^rftrrt table. spend to columns of <tabieName> having the same 

Thus, to insert all the data about the engine and its names, 
gubptm using tms invention requires only the single 30 Syiitax (or Update Statement 

query, m contrast to the forty-three queries of the prior a3ruw * *^ 

art The UPDATE s tate ment updates dtom the columns 

* j- * of pre-existing row ma specified b^ 

Syntax for Insert Statement amimand used m the preferred embodiment for updst- 

pw^pi^ q*~y ^flT ap ge ifi ed 35 mg data previously stored in the datab as e has the foJ- 

below using a modified form of "Backus-Naar Form** lowing format, denoted in modified Backus-Naur form: 
(BNF), a notation commoaly used to describe computer 
pj o gram mmg languages. Statements are described by 
giving their syntax in terms of entities and keywords. n^n— M .,t 

Entities are represented as a word enclosed in angle 40 < " -J^upda'TE <t4bfeNvat> 
brackets r< M «nd N >* v >- Keywords are shown as capi- " { using aro [as <iwnfcaiwMir > ] 1 



tallied words not enclosed in brackets. Bracketed enti- <api«eS|»dflcste> L <*d*tS»«ciAcat»oa>]» 

ties are defmediismg the symbol M n«^ Soiiare brackets I where <—fcsCondirioa> l 

<T* and T") enclose optional portions of the syntax. If 

a right square bracket is followed by an asterisk ("""X 45 This sutement is interpreted as follows: For each 
the entities and keywords within the brackets may record REC in the directed graph data structure whose 
occur zero or more times. An asterisk that does not corresponding base table is <TabteName>, locate the 
follow a right square bracket is taken btersHy. row R of table <tableName> whose primary key 

The Query command used in the p ie fcr re d embodi- matches the primary key of REC. If <searchCond»- 
ment for inserting or storing data into the database has 50 tion> is true (ie- when applied to REC and/or R). 
the following format, denoted in modified "Backus- update row R as specified by the <tmdate5pecifica- 
Naur Form**: tion>s. An example of an <urxiateSpecirkation> is 



< ''^-"nSsEBT [INTO) <ab>tWmf> K <iMcrtUtf > H <-M9pe>c> 

<narirl,at> _ ^ j u iw rT ssii: r 

<lsscrtS^sc> 

=. VALUES <vslaaSs«c> t <wha Sg« c > ]* 
SELBCT [ALL | DISTINCT] Qffcrfl wt> 
FROM <**fttExpraMfc»> [WHERE <«McaCoadtfoa> ) 
=- VSD9Q ARO £ < vritrt s f > ) 
[ WHERE <sewcsOndaioa> ] 




Thus an INSERT statement is used to insert a di- 
rected graph, or specified portions of a specified di* 
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-SET A^NEWA". If the optional <correUtion- 
Name> b not given, its default value » "HEW. The 
fields of REC may be referred to in <searcb€ondi- 
tkm> 



18 

CONVERTING A DIRECTED GRAPH INTO 
INTERMEDIATE FORMAT 



<oorrdatk»N«aK>.<&kSNtixit> 



An example of an UPDATE 



UPDATE Ti 
USING ARO 

SET a — mew*, b — acwa * 



SYNTAX FOR DELETE STATEMENT 

The Query command used in the p ref er red entfxxb- 
for deleting data previously stored in the database 



has the following format, denoted m 
Nanr form; 



Backus- 



The following description includes pseo d oco de rep- 
S mentations of the software routines relevant to the 
present invention. The pseudocode used herein is, es- 
sentially,, a computer language using universal com- 
puter language conventions. While the pseudocode 
employed here has been invented solely for the pur- 
10 poses of tfafed^scriptkm.fttta^s^ 

derstandahlr by any computer progra mm er stalled in 
the art. The computer programs in the preferred em- 
bodiment are written primarily in the MAINSAIL pro- 
grammmg language, compilers for which arc commer- 
13 ciaDy available from Xidak, Inc. of Palo Alto, Califor- 
nia. 

Referring to FIGS. 3, 7 and «, the procedure used by 
the data translator 236 in the mter&ce 232 to convert a 
specified directed graph data structure into the mterme- 
diate data format shown in FIG. 7, is as follows. 

PSEUDOCODE FOR STORING DIRECTED 
GRAPH IN BUFFER 



INITIALIZATION: 

CLEAR HASH TABLE -(imHO.S) 

CLEAR LIST KJECS FOR STORING RECORDS 

CLEAR LIST OF TABLE DEFINITIONS TDEP ' 
STORE IN TDEF THE TABLE D tiMNI 1MJN S FOR ALL DISTINCT TYffCS 
OF RECORDS THAT ARE TO BE INSERTED INTO THE DATABASE 
STORE TOP LEVEL RECORD IN RECS 
STORE CORRESPONDING ENTRY IN HASH TABLE 

FOR EACH RECORD IN RECS (BEOINNINO WITH TOP LEVEL RECORD) 

FOR EACH POINTER fN RECORD 

RR — RECORD POINTED TO BY POINTER 
IF RR IS NOT ALR EADY IN HASH TABLE AND 
RR MEETS SPECIFIED <«tfcaCoadtaka> 
ADD RR TO HASH TABLE 
ADD SPECIFIED FIELDS OF RR TO RECS 

ENDIF 
ENDLOOP 

USE LINK. IN HASH TABLE TO FIND NEXT RECORD, IF ANY 

ENDLOOP 

STORE TDEF AND RECS IN BUFFER FORMAT SHOWN IN FIO. 7 



n» delete from <wbkNi»e> «fcku£pec> The initialization step in the above pseudocode rou- 

«WeieSpec>__ i _ r tL ^ 45 tine sets up an empty hash table and two fasts: one for 

=- where <K«cKMnm> records called RECS and one for table definitions 

~_ USINO ARO (AS <co mto Ntae> ) called TDEF. Table definitions for all the distinct types 

{WHERE <wMcfcCcw dit inB> 1 of records that are to be inserted into the database are 

added to the TDEF fast 

The DELETE statement is int erpre t ed as follows: 30 The hat of records in the application interface Urftti 
For each record REC m the ARG directed graph data *2 is corjstrmcted by visiting each record b Acfr 
stracture, locate the row R of table <tableName> rected graph ^.^m^ «^ and recoromgjts 
mttw^ r* im«Y v#y nmirttm* t hr pr * mM y **y rf EEC if associated mformation m the boner. More ipecmcajly, 
<searchConditkxi> is true (Le», when appBfd to row every record r e a ch ab le from the specified starting re- 

R and to record REQ, delete row R from <ta- 55 cordis proccaacd. ^ _ . 

bkNsme>. If the optional <correhUk»Name> is not To rirevent storing a record more than once, which 

given, its ddanh value is "NEW\ Fields of REC may would be the cas e whe n the directed graph — ' 

be referred to m <aearchCbndition> oamg cycles or multiple pointers to one record* the 



^cocwhrinaN— c ^ » <BeMNm 


■e> 


An example of a DELETE statem 


ent is: 


DELETE PROMT! 




USINOARO 





tion interlace checks, apoa visrttag each potmttatry 
new record, whether that record is already ia the RECS 
fiat (by looming for the record in the hash table 490% and 
if so, it does not process that record any farther. If the 
record has not already been visited, the application 
interface checks the s peci fi ed < tearchOnriflition >• to 
65 determine whether to add thn record to the RECS hsL 
If so, the fields of the record specified by <varoes- 
Spec> are stored as a new row m the RECS hst The 
record is also added to the hash table. Then the buffer 
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bafldmg proem moves onto the next record found untO t match » found. It then know* the name of the 

using the link field of the bash table. table in the database that corresponds to REC 

When afl the records of the directed graph have been Another feature of the preferred e mb odime nt, which 

visited, the resulting lists TDEF and RECS are stored improves efficiency by reducing the number of distinct 

in the application interface buffer 241 in the format 5 (penes to be processed by the DBMS, is that the proto- 

sbown in FIG. 7, which was described above. col between the application mtrrfacr and the DBMS 

Next, the list of rows 24* in buffer 242 n transmitted aDows more than one query command to be transmitted 

by the application interface 232 to the corresponding m a pin of a single query string. More particularly, a 

application task 212 m the DBMS process 210, along transmitted query string can contain several 

whh th e command (Le* INSERT, UPDATE or DE- 10 ^^..^ separated by rr - '~*™ * <Le^ 

LETE) which is transmitted to the DBMS by software ryl <mery2; -"). Thus, a multiplicity of INSERT, DE- 

module 234 in the application interface, LETE and UPDATE statements may be associated 

Tne list of rows 246, dow id buffer Ml of the sppbes- ^ directed graph data structure, 

tion task 212 in the DBMS, are then either added to the ^^^b^TSScrUve and nawleacriptive 

specified target base table, c< to iipdate pre^t- 15 ^Z^S^L^ uVdSSve 

ing records m ^target base ta ble (if the appbcsftOQ*s ZS^tfn.. ^ tfrft Mm^t iAn tff^> ^w**g 

foT^prc^theRele^ 

feteniiedufe buffo fo^ type of record .m the directed gra^daU rtructure, and 

with the imnnu^ key vahiestf 20 «■« *—* « correupcsiateg astefcese teMe. 

the target base table. RETRIEVING A SPECIFIED PORTION OF A 

When a nwdification query that c ontain s a USING DIRECTED GRAPH 

ARG clause is issued by an application, the ap pl ic ation . . ^ , ^ . . 

must provide additional declarative mfbrmatioo to the hi general, data n retrieved from any database by 

application mterface to enacted 25 aending a query to the DBMS 200. The DBMS 200 

dirrcifd graph data rtrvcrvrr, *nAtr%*nah>lt> H to mi. interprets the query, generates a set of detailed ■nstrno- 

ate each type of record in the directed graph date struc- bona for eiecutiiig the specified query, and either re- 

tore with n particular table in the database. This addi- terns the requested date or an error cede that explains 

tional information is provided along with both the why it is unable to comply with the query, 

query and the directed graph date structure (ARG) 30 For instance, referring to the table 400 shown in FIG. 

itself. Can example retrieval query using prior 

For programming languages, such as the C t a n gn agr, be: 
thai do not repreaent date structures m a se^ 

way (at nrntaoe), the additional declarative information ■' 
must include the following information for each distinct 35 
type of record in the directed graph date structure that 

is to be sent to die DBMS: 

1) Thenajnecrfeachfieklmtrjiire 

be passed to the DBMS. When applied to table 400 in FIG. s\ tins query re- 

2) Tnedisp)ac*ii>emofeac*isuchf 40 quests the DBMS to retrieve the row of the base table 
of the record. whose partName is "ENGINE". This prior art query 

3) The type (e.g.,mteger, string, d retrieves only one row of the table: the row with a 
such field. partName of "ENGINE*. Of course, another prior art 

4) If the field is a pointer to a record, the name of the query could be used to retrieve all the rows cf the table 
database table c o rre sp onding to the pointed-to 43 400 which have a PartName beginning with the string 
record. "PISTON", which would resuh in the retrieval of eight 

5) The name of the table in the database to which this ^ ^ for piSTON 1 through PISTON ft. 
record type coiresponds . More importantly, the prior art query for retrieving 

In addition, the record description that corresponds the "ENGINE" row does not retrieve any information 

to the top-level record in the directed graph date struc- 50 ^ ^ ^ B m ^ ^ — ^^^^ ^^^ 

tare most be identified so that the application interlace t3j . ^ £T tfcMW ^ ^ ^ dkx;aMioci ^ 

bows how to T*gin" its traversal of the directed a ^ m ymioa tftiaae taMe 400 wouM 

•W*- . , have the names of the eiiga**scxmpc*entB stored m the 



WHERE putfaat - *BmiNB* 



k to te ^to AeDBMsT ktywonh, EXPAND and DEPTH, for crartrolKng the 

I) An m*uoe of Uts type of record, referred to «a « retrieval of directed graph date MUvOumJ m the pre- 
"model record" ferrcd embodiment, whenever a SPJ n ; i statement 

7)Ty r .^^t^t^mt»^riW^towl»kAthk mclades the keyword EXPAND (and does not include 
type of record corresponds. keyword DEFTrl> the DBMS process wffl respond 

The model record* used as a template ag^ to SELECT query by retrievmg two sets of date: 

records encountered m the traversal of the directed 65 0) all rows, or specified portioBS of rows, which 
graph date structure can be matched. For each record meet a specified set of con dit ions, which are typt- 

REC encountered, the application interface cosnpaxes caHy denoted by s WHERE or HAVING clause m 

the REC*s type with each of the model record type's the SELECT statement; and 
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(2) aD rows, or specified portions of rows, which are -continued 
pointed to by Reference pointers in other rows of 



dsia retrieved in response to the q^ wmR^pSSto - «enoini? 

It a important to note that the second category of — ■ 

data which is retrieved is a recursive definition. In other 3 . . . . 

words, the DBMS process continues to retrieve data Note that the -parts- tabic n the table 400 shown m 
until all rows which are pointed to by any previously FIG. «. Like the prior art query, this qiieiycommutds 
retrieved row have been retrieved. the retrieval of the row in table 400 for "ENGINE . 

The purpose of the DEPTH <n> clause m the SE- Call this row the top-level row. The EXPAND clause 
LECT statement a to h^ the amount of daU 10 

by a SELECT statement which includes the EXPAND 

keyword. In particular, whenever a DEPTH <n> •expand imt**r 

dausc is used, every row of the specified table which is ' 

retrieved must by f i r f pirt^tf to one of the retrieved 

top-level row<s)by acham of n-1 or fewer pointers. 15 directs that whenever a MFEKENCE to the table 
In the preferred embodiment, the extended SQL syn- called parts is encountered m any retrieved row, the 
tax for query tHrct ttttfmfft H p rov id ed by the present reference is to be followed a wxwflm g to the csp a imfm 
tti**r nt wm. drnfttr d m r*^*rfi*4 "fftr*™-**-" Knrm» i»* process described above. Thus, referring to FIG. 4, not 

only is the row for "ENGINE" retrieved, but also the 



*> 

=- SELECT [D15TINCT | A1XJ <ickctLfct> FROM <ttbleExpK«KJB> 
| OfUXER [BY) <«rtOotam> l<wnCokmm>r 1 
<tdectLki> 

=- <vritEiytMiM> IAS <cd— iNM^>]t OilirUirt>l* 



< tt b kH ifci c a cc> l <* 
[EXPAND [DEPTH <»>1 <rip— irw^pfQ f, <o|)nMaSpce>]* 1 
| WHERE <MsiGfaOnMitk»> ) 
lOROUPPyi < o nlmVtfr i fMinn > 

[ HAVING <KMctCoaafdoa> ) 

> 

=- <UfckNt> [AS <i nmhtlnatl— a>] 



=- <*MeN*ne>[(< 

[WHERE <csp 





It should be noted that all aspects of the shove defmi- ten rows with partName's of CAM SHAFT, CYLIN- 

bon are the same as prior art SQL, except for the EX- DER 1, CYLINDER 2, CYLINDER 3, CYLINDER 
PAND. DEPTH and <ezpjmskmSpec> terms. An CYLINDER 5, CYLINDER 6\ CYLINDER 7, 

<r » r ^*^ w g r ^ > *»\u to ~^mmA ^h—m. Art CYLINDER S, and WATER JACKET, 
are REFERENCES to a specific table. In other words, 30 •dVhtion, amoe tf*** tow% ■j* 0 * ?* t ^ n " 

it specifies which table and which reference in sFarts column with references to other tows in the table 

twt table are to be used for expansion. The <eBpan- Fsrts, the npansion process continues with these rows, 

ssonSpec> clause can also specify logical cwtitvm «* so on. Specifically, each of the eight cyhnders rows 

which hmh the rows that are retrieved during expan- have references to an eshaust value, an intake valve, a 

floo. 23 piston, and a spark ping. Together, the rows for the 

Consider the effect of adding an EXPAND clause to eight cylinders reference thirty-two snore part rows 

thf qimy if mr rtt d fr» *~ "tntnnnr that are also retrieved, sraefy the rc^ for the psffte 



EXHAUST VALVE I INTAKE VALVE I F1STON I gPARKFLUOl 
EXHAUST VALVE 2 INTAKE VALVE 2 ffiION2 SPAKK HXJO 2 

EXHAUST VALVE I INTAKE VALVE S WSTONt SPAKKFLUGt 



, V1 Thus, the above query with the EXPAND l, 

row of the partt base table: 65 tion causes the top-level row and forty-two additional 

rows reached through the tc^levdrw to be retrieved, 
or forty-three retrieved rows in totaL The add i tional 



zuzugcf * ~— ™ - — 

ntOMpsm forty-two rows retrieved by this query arc structurally 
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t^tod to the top4evd row through a The candidate columns tor expansion initially come 

from the top-level row ("ENGINE") to each of the from the commits whose names appear in <selectList> 
other rows retrieved of the SELECT cofmnand. Once a column M c~ that 

Without the optional EXPAND clause, data stored in refers to row *V b expanded, any columns of "r" that 
die cohmms specified ia the <sefcctList> of a SE- 5 meetcxnditkmft ffts^ 

LECTcominaixl are copied hrto a ^ become candidates lor expansioo themselves, at the next 

the application program. Retrieved data from cohimns higher depth level 

with a datatype of REFERENCE is stored in a field or The optional DEPTH clause bnrits the expansion to 
fields of the appfcarion't -top-lever record(s) that <n> levels. Specifying a depth of one (1) feuts the 
contain the foreign key viJues a norfr*T^ with the refer- 10 retrieved data sliuctme to one or more "top-lever 
ence. records, which directly meet the criteria of the 

The optional EXPAND clause m a SELECT state- "WHERE" clause in the SELECT statement, with no 
meet causes the specified REFERENCE columns to be other records below the top-leveL A depth of three 
expanded. A columa of type REFERENCE b said to imita the expansion to three levels, uwdudks the top- 
be expanded if it is retrieved into the application pro- 13 level row and up to two levels below it Note that the 
g^am as a potnter to another record, rather than as the retrieved records, rrgsrdlrts of the specified DEPTH, 
foreign key values associated with the reference. The wfll contain only those fields which correspond to the 
columns of the expanded row themselves become can- columns in <trlrctlist> of the SELECT statement 
I M-lf f for further tj p" * ** ™ In the preferred embodiment, the depth number ap- 

Only those cc4imms that are of type REFERENCE 20 plies specifically to a ^nxadth first" eipansioo process, 
are r^r*"**- 1 If the < expt*»6<fchimnUst > ta the EX- Thus, the retrieved directed graph data structure may, 
PANDdauseb^thenancohmm m general, contain cycles and/or nruhiple pointers to 

fied by the EXPAND clause are expended If the <ex- the same substructure, and thm there may 
panskmSpeo m the EXPAND clause is then all the top-level record of the structure to odier records in 
columns of all tables not mnrn^""* in an rT*"^* 1 23 the sH e ctur e that exceed the sp ecified depth. In other 
clause arc expanded m their entirety, fiairted only by the words, if the specified DEPTH is equal to a positive 
DEPTH specified, if any. integer n, and if the minimum number of references 

Specifically, consider a column "cT whose type b leenired to get from a top-level row to a particular 
REFERENCE and that refers to a particular row *Y* in second row b leas than n, then that second row a re- 
table *V. Column M c" will be expanded if all of the 30 trieved even if there are other paths between the top- 
following condrrtpfH are met: level row and the second row which trav^ 
(i) an EXPAND clause b present and the EXPAND reference pointers, 
clause specifies that references to table "Y* are to be During a reference expansion, if a r e fa enc e bincom- 
f HpfryH; plete (contains at least one NULL key value) or refer- 
(n) the "WHERE" condition associated with the 33 ences a non-exbtcnt row, the reference b returned to 
particular <expansionSpec> used b TRUE for the application as a NULL pointer. Similarly, if the 
row *V, or there b no such "WHERE" condition; DEPTH b ex c re dfd, the reference b returned as a 
and NITIX pointer, 
(m) the Dumber of p revio usl y PirpiiHfrti rows re- The data structures that may be retrieved as a result 
quired to reach row "jT does not exceed the 40 of a SELECT with an EXPAND clause include n-ary 
-DEPTH" number given in the -EXPAND" trees (n-f* 1, 2^~X hnked fists, end; in general any 
clause, or there b no DEPTH limit directed graph data structure, IT the data m the database 
The columns of the row "V that are retrieved and refer to the same row more than once, only a smgje 
that become possibly r*"^-** for expansion them- instance of the rowb retrieved Thus, osdy a single copy 
selves are limited to the columns that appear in the 45 of each unique database row will be retrieved and 
<cxpandColumnIJsl> following <tableName> **t" stored as a record in the directed graph data structure 
in the expansion clause. If the <expandCorumnLbt> that b sel e ct ed 

Mt fKiy*^ with table *t" b "+**• then all columns of Referring to FK3S. X 7 and t, the pr oced u re used by 
table "Tate retrieved and are candicUtes f or exparision. the DMBS to perforin an expanded SELECT qnery 
SmsOariy, if the <expansionSpec> appears, and 30 and to store the retrieved data in the mtennediate data 
<tableName> *V does not occur m the EXPAND format shown in FIG. 7, denoted in p aeudocode form, b 
clause, then all columns of table T* are retrieved and aa follows. 

■ candidates for expansion. PSEUDOCODE FOR RETRIEVAL WITH 

TRANSITIVE CLOSURE 



INITIALIZATION: 

CLEAR HASH TABU 

CLBAMUSTWmaW%FO*STOUHQME19aVEDWnrWS 

CLEAR LETT OF TABLE DWINJIIOIO TDEF 
RETRIEVE TOP LEVEL ROWS IN ACCORDANCE WITH UNEXPANDED 
SELECT STATEMENT 

SPORE TABLE DEFINITION FOR TOP LEVEL ROWS IN TDEF 
STORED TOP LEVEL ROW(S) IN RJtOWS 

STORE CORRESPONDING ENTRY OR ENTRIES IN HASH TABLE 
FOR EACH ROW IN RROWS (BEOINNINO WITH TOP LEVEL ROW) 

FOR EACH REFERENCE ON ROW) MENTIONED IN EXPAND CLAUSE 

RR « RECORD POINTED TO BY REFERENCE 

IF RR B NOT ALREADY IN HASH TABLE 
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^onturued 



RR MEETS SPECIFIED WHERE <MMtfcGoaditioa> AND 
AND 

DEPTH OF RR FROM TOP LEVEL ROWS DOES NOT 
EXCEED DEPTH LIMIT 

ADD SPECIFIED COLUMNS OF RR, INCLUDINO 

CALCULATED VALUES, TO RROWS 

IF TABLE DEFINITION FOR RR IS NOT ALREADY IN 

TDEF 

ADD TABLE DEFINITION FOR RR TO TDEF 
BNDIF 

ADD RR TO HAS TABLE 

ENDIF 

pj^ploop 

use link in hash table to find next row. ef any 

ENDLOOP 

STORE TDEF AND RROWS IN BUFFER FORMAT SHOWN IN FKL 7 
TRANSMIT DATA IN BUFFER FORMAT TO APPLICATION INTERFACE 



The kutiifi ration step » the above pseudocode too- 
tine sets up sn empty bash table and two lists: one for 
retrieved rows called RROWS and one for table defmi- M 
toons called TDEF. Table definitions for all the distinct 
types of rows that are r e ti icved (Le^ from distinct base 
tables) are added to the TDEF list as the Hat of retrieved 
rows is accumulated. 

The list of rows in the DBMS application task buffer 25 
141 is constructed by visiting each r e tr ieved row in the 
RROWS list once, and eipandmg those reference col- 
umns denoted in the EXPAND clause. Notice that each 
expansion of a row may add new rows to the end of 
RROWS. When the last row of RROWS is expended, ^ 
the transitive closure has been computed. The expen* 
saoo process must eventually reach the end of RROWS 
because duplicate rows are not added to the RROWS 
list, and there are a finite sniniberof rows m any data- 
base. 35 

To prevent storing a record snore than once, which 
would be the case when the directed graph contains 
cycles or multiple pointers to one base table row, the 
DBMS checks, upon visiting each potentially new row, 
whether that row is already in the RROWS list (by 



<selectList> are stored as a new row in the RROWS 
list. The row is also added to the hash table. Then the 
butler building process moves onto the next row in the 
RROWS hst, which is found using the hnk field of the 
hash table. 

When all the rows in RROWS have been visited, the 
resulting lists TDEF and RROWS are s to red ma buffer 
141 by the DBMS in the format shown in FIG. 7. This 
retrieved data is logically equivalent to one or more 
derived tables. A derived table is a subset or portion of 
a base table from which data is being retrieved. The 
retrieved, buffered data is transmitted to the application 
interface 230, which then converts the retrieved list of 
rows into a directed graph data struc tu re suitable for 
use by the application p ro g r am which ge ne rate d the 
retrieval Query. 

Referring to FIG. 7, tiie procedure lor converting the 
retrieved data (stored m buffer 342 m the intermediate 
data format shown in FIG. 7) into a directed graph data 
structure, denoted in pseudocode form, is as follows. 

PSEUDOCODE FOR CONVERTING 
RETRIEVED DATA INTO DIRECTED GRAPH 



READ RETRIEVED DATA IN APPLICATION INTERFACE BUFFER 

ALLOCATE AN ARRAY OF POINTERS REFROWS TO STORE POINTERS TO 

EACH OF"THE ROWS IN THE BUFFER 

FOR EACH ROW R IN THE BUFFER 

ALLOCATE A RECORD THAT CONTAINS FIELDS FOR EACH OF THE 
RETRIEVED COLUMNS OF DATA, AS WELL AS ANY ADDITIONAL 
FIELDS SPECIFIED BY THE APPLICATION PROGRAM 
(RETRIEVED DATA IS INTERPRETED USING THE CORRESPONDING 
TABLE DEFINITION IN THE BUFFER) 

STORE POINTER TO ALLOCATED RECOUP IN OOSIRESPONDINO 
* POSITION OF REFROWS 
ENDLOOP 

FOR EACH ROW R IN THE BUFFER 

STORE DATA FOR THE ROW R FROM THE BUFFER INTO THE 
Al J /VMTPTfc R BCT*J> 

FOR EACH FIELD IN THE ALLOCATED RECORD WHICH 
CORRESPONDS TO AN EXPANSION COLUMN 

REPLACE ROW NUMBER (N) WTTH POD4TER IN REFROWS (N) 
ENDLOOP 
ENDLOOP 

ARO « FIRST PC4NTER IN REFROWS- * akm to Top Iw d 
DEALLOCATE REFROWS ARRAY 

PASS ARO TO APPLICATION PROGRAM 



looking for the row in the bash tatjfc 490), and if so, it 

does not process that row any farther. If the row has When a SELECT query with an EXPAND clause is 

not already been visited, the DBMS checks the speci- 65 specified, the application interface uses the declarative 

fled <ei|»nskttPredicate> (which is a type of search mformatkm about trie taMesmv 

condition) to determine whether to add this row to the table definition portion of the buffer that it receives 

RROWS Hal. If so, the ootnmns of the row specified by from the DBMS, to transform the "flat" buffer repre- 
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automatically ooo verts directed graph data stroctujes 
into table form, and vice versa, thereby reducing the 
complexity of engineering application pio giam s which 
use a DBMS to atore directed graph data sliu c Uu c s . 

While the present invention has been described with 
reference to a few specific embodiments* the descrip- 
tion is Qhmrative of the invention and it not to be con- 
armed as limiting the invention. Various modifications 
query with an EXPAND clause a issued, the appbea- may occur to those skilled in the art without departing 
non interface accepts from the application program 10 from the tnie spirit and scop^ 
some optional record descriptions, in conjunction with by the a p p en d e d claiwit . 
the query itsdf, that aubles the appixaiic* program to What hi claimed is: 

specify the exact memory layout to use for each table L A computer system for storing, retrieving and 
whose rows are being retrieved as part of the directed modifying data stored m a database, um i jwising: 
graph data structure. IS a da l a h a ar server; and 

The form m which record descr ipti ons arc provided a multiplicity of apfrfkatkm processes coupled to 

database server, each application process incrad- . 



sentation into a directed graph data structure in the 
apphca t son pi ogi ammtng language*a represent at io n . 

Each application programming language has its own 
data structure rcpresentatioB mechanisms and its own 
data types. Thus, the representation of retrieved di- 
rected graph data structures differs somewhat from one 
computer programming language to another. 
In the pr e f erred embodiment, when a SELECT 

the appbea- 



is smnlar to the way records are described when a 
USING ARO query is issued, as described above. Dar- 
ing the translation of retrieved data (stored in the inter- 
mediate buffer format) into a directed graph data atrnc* 20 
tare, the a pp lica tion interface uses the record descrip- 
tions for each type of record being retrieved to decide 
how to allocate the record and where to store each 
field. 

Allowing the application to provide this optional 25 
reformation has two significant advantages. Hrst, it 
ensures that a record trmphtr can be declared in the 
application programming langnagr to match the re- 
cords constructed by the brterface. Thus convenient 
language constructs can be used to access records. Sec- 30 
h allows the application pr o gram to include m 



35 



each record some additional fields that do not corre- 
spond to retrieved data, but that the program may need 
to perform certain operations on the l e c or d s An exam- 
pie of an additional field is a flag field that the apphca- 
tion program can set during its own processing to mark 
that a particular record should be modified or deleted in 
the database This field may then be referred to i n the 
<searchContftion> associated with a later DELETE 
... USING ARO query, for example. 40 

In sunimary, the directed graph data structure b gen- 
erated by storing each row in the buffer in the form of 
a record in the format exp ec te d by the ap p lica t ion pro- 
gram. Further more, expanded references which are 
r e p r e sen ted in the intermediate buffer format as row 45 
numbers are replaced with pointers to the correspond- 
ing records in the converted data s tiu c tui e. The result- 
ing data structure is then passed by the application inter- 
face 233 to the apfmcation pt o giai n 230. 

CONCLUSIONS AND ALTERNATE 50 
EMBODIMENTS 

It should be noted that the processing of each query 
by a DBMS requires a certain amount of system re- 
sources to process the awry . regardless of howstmpfe 35 
or complex the query command may be. Thus it takes 
considerably less system r eso ur ce s for a DBMS to pro- 
cess a single extended query than it takes to fatness 
numerous prior art queries, even though the s ingle 
query letrieves the same amount of data as the nuxser- 60 
oua prior art qui li e s 

In various uses of the present invention, the number 
of prior art queries replaced by single extended query 
will depend on the complexity of the data structures 
being used and the amount of data that needs to be 45 
retrieved. In some contexts, a single extended query 
may replace hundreds of prior art queries. In addition, 
the application interface fcam^ 



I graph 

data structures in a co rresp o n d in g ap pl ica ti o n 
specific data format; each said directed graph 
data stiuctuie including one or more r e cor ds of 
data isrtcrconnected by pointers* each record 
composed of one or more data elements having 
l e ap e oi ve specified data types; 
an nppl scation interface that translates directed 
graph data s tr uct u res in said application specific 
data format into a predefined intermediate data 
format and translates directed graph data struc- 
tures in said pred efu a rd intermediate data a for- 
mat into said application specific data format; 
and 

query gf »f rating means fig generating and aending 
queries to said database server for storing, re- 
trieving and updating specified directed graph 



including: 
for 

schema for each of a plurality of tables in said 
data ba se , each said database table having a plu- 
rality of rows and a specified number of col* 
umns, wherein each row of said table stores data 
values in each of said cc^unmsc/ said table; said 
schema denoting a data type for each column of 
data values stored in said table, each denoted 
data type being selected from a set of p red efi ned 
data types including a reference data type; 

each non-empty data value stored in a reference 
data type column eonujmsmg a reference to a 
row of one of said tables in said database; and 

directed graph storage means for storing and re- 
mevmg speoncn oxrecseo grape cam suuciurcs 
in and from sp e cifi ed tables in said database in 
accordance with queries received from said ep~ 



graph storing means for receiving a < 
query that sscludee a specified directed graph 
m bums preoenneu mxeriueoiauc 
> and for storing each record of said 
reeled graph data structure in a dis- 
tinct row of a respective one of said tables m said 
database, said graph storing means including 
means for storing said data rlemrnts of said each 
record in corresponding columns of said one 
respective table and means for stirring refer- 
ences, each re fe rence corre sp onding to one of 
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to other records of said specified directed graph 
date structure, m corre sp onding ones of said 
reference data type columns of said one respec- 
tive table; and 
directed graph retrieving means for retrieving a 5 

specified directed graph data structure from said 
. database in accordance with a single specified 
query received from ooe of said application pro- 
cesses, including means for retrieving in accor- 
dance with said specified query at least one spec* 10 
ified row from at least one respective table m 
said database and then retrieving additional rows 
of data from r e sp ec ti ve tables in said database, 
said additional rows of data comprising vows of 
data that are referenced by references m other 15 
rows of data retrieved in accordance with said 
specified query* for converting said retrieved 
rows of data into a directed graph data structure 
in said pr ed e fi ned htffTFMitfatf data format, and 
for transmitting said retrieved directed graph 30 
data structure to said one application process; 
whereby a directed graph data structure ha ving mul- 
tiple records » retrieved by said 
response to a single query from said one application 
process. 23 
2. A computer system asm chum 1, 

m$ flwwni m g jn each said 
a table identifier for each reference data 
type column, aaid table id rntifi r r sp ec ify ing which 
database table is r e f eren ce d by r e f er ence s m that 30 
column; 

each said table m aaid database having an a ssoci a te d 
primary key compnsmg an ordered list of columns 
of said table whose values identiry a parncular row 
of said table; and 35 
each of aaid r e f erences coniprising a primary key 
value of a row in the r e sp ec ti ve database table 
specified by the schema for the table in which each 
said reference is stored. 
& A computer system as in churn t, wherein each 40 
directed graph data structure in said mtermediate data 
format includes rows of data values, each row of data 
values correspo n din g to a respective record of a corre- 
sponding directed graph data structure in one said ap- 
plication specific data format, aaid rows of data values 45 
including row pointers interconnecting aaid rows of 
data values, each row pointer corr esp o ndin g to a re- 
spective pointer in said corresponding directed graph 
data structure in one said application Tp t rifi c data for- 
mat. 50 
4. A computer system as in chum 1» 
said query generating means including means for 
including in said generated queries specified crite- 
ria for limiting retrieval of said additional rows of 
data. 55 
& A computer system as m claim 1* 
said query generating means mriurimg means for 
jachwting retrieval banting criteria in ones of said 
aaid retrieval minting criteria 
i depth, said sMihmm depth 60 
[ amaxnnam number cn* pointers used m 
to interconnect one or snore top-level 
recoros or saw speonco uuecuo giapn cuua arruc* 
ture with other records of said specified directed 
graph data structure; and 65 
said directed graph retrieving means includin g means 
for limiting retrieval of said additional rows of 
data, when retrieving a specified directed graph 



data structure in accordance with a query includ- 
ing retrieval limiting criteria, to those of said addi- 
tional rows of data that are c on necte d to said speci- 
fied at least one row of data by a sequence of 
eaces no greater in number than said maximum 
number denoted by said retrieval limiting criteria. 
6. A computer system for storing, retrieving and 
modifying data stored in a database, comprising: 




a multiplicity of application processes coupled to said 
database server, each apphcation process includ- 
ing: . m 

an application program that utilises directed graph 
data structures in a corresponding application 
specific data format; each aaid directed graph 
data structure including one or more records of 
data mteroonmectcd by poin t e r s, each record 
composed of one or more data e le m ents having 
respective specified data types; 

query generating means for sending queries to said 
database server for storing, retrieving said updat- 
ing specified directed graph structures in said 



at least one application interface that translates di- 
rected graph data structures in one resp e cti ve ap- 
phcation specific data format into a predefined 
jntennediatf data format and translates directed 
graph data structures m said p r e defi ned mtermeoV 
ate data format into said one respective application 
specific data format; said at least one apphcation 
interface coupling aaid database server to a rcspec- 
tive at least ooe of said application processes; 
said database server mcfnrimg- 

for ^s*finiHj ft chstinct 
i for each of a plurality of tables in said 
dat a base , each said database table having a plu- 
rality of rows and a specified number of col- 
umna, wherein each row of said table stores data 
values in each of said columns of said table; said 
i denoting a data type for each column of 
stored in said table, each denoted 
i type being selected from a act of predefined 
data types tnchyting a reference data type; 
each non-empty data value stored in a reference 
data type column comprising a reference to a 
row of one of said tables in said database; and 
directed graph storage means for storing and re* 
tnevmg specified directed graph data structures 
in and from specified tables in said database in 
accordance with queries received from said ap- 
pbcation processes; 
aid directed graph storage means including: 
graph storing means for receiving a data st o ra g e 
pjuery mat includes a specified directed graph 
data structure m said p r rrtrfiiind intermediate 
data format and for storing each record of said 
received directed graph data structure in a dis- 
tiact row of a r e sp ec ti ve one of said tables in said 

Bseens Joe storing sasd data elements of aaid each 
record in 'y ding columns of said one 
respective table and means for storing refer- 
ences, each reference corresponding to one of 

— > -» ka^a^m afc ■ * * — ■* - ~ — * -* * - ■* 

saw pomi er s wax interconnect sato cacn recora 
toother records of said specified directed graph 
s tructur e, in corresponding ones of said 
: data type oohnuns of said one respec- 
tive table; and 
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directed graph retrieving mfans for leuieving a 
specified directed graph front said da tab as e in 
accordance with a tangle specified query re- 
ceived from one of said application |*utiiiri, 
mf>^w«tig means for retrieving in accord an ce 5 
with said specified query at least ooe specified 
row from at least one respective table in said 
database and then retrieving additional rows of 
data from respective tables in said database, taid 
additional rows of data coinprismg rows of data "> 
that are referenced by irfciei K C S in other rows 
of data retrieved in accordance wife said speci- 
fied query, for converting said r e tri eved rows of 
data into a directed graph data structure in said 
prede fin ed mtennediate data a format, and for 
transmuting said letricved directed graph data 

whereby a directed eTajm 
retrieved by said datahtsr server ia response to a 
signal query from said one application process. M 
7. A computer system as in claim Sv 
said schema defining means denoting in each said 
schema a table identifier for each reference data 
type colimin, said ta4fe 

; table is referenced by references in that ~ 



32 

no greater in number than said maiimom 
number denoted by said retrieval limiting criteria. 
11 In a computer system, n control proem of storing 
and retrieving directed gra|« d^ st ro ctuies m a d^ta 
table is a computer system; said computer system hav- 
ing a multiplicity of application processes coapkd to a 
database server that respcoc^ to queries from said a|>pfr 
catkm processes by storing, retrieving and updating 
data in said database; the steps of the control process 



19 



each said table in said database having an i 
primary key comprising an ordered hst of columns 
of said table whose values identify a particular row ^ 
of said table; and 

each of said references co mp ri si ng a primary key 
value of a row in the respective database table 
specified by the schema fc* the tabk m wtocfa each 
said reference ia stored. 35 

ft. A computer system as in claim u\ wherein 



format includes rows of data values, each row of < 
values exxTTtponrimg to a respective record of a corre- 
sponding directed graph data stiucture in one said ap- jq 
plication specific data format, said rows of data values 
including row pointers interconnecting said rows of 
data values, each row pointer corresponding to a re- 
spective pointer in said corresponding directed graph 
data structure in one said application specific data for- 43 



for 



9. A computer system as in claim 6, 

said query generating means including 
a— Minting m said generated queries specified < 
ria for limiting retrieval of said adVihicoal rows of 30 



10. A computer system as in claim a, 

said query generating 
w*H i tt*« g retrieval hunting criteria m < 
generated queries, said retrieval hmitiag 
i fam i in j a maximum depth, said * iai '""" l> depth 

mpir^T^ interconnect one or more top-level 
records of said specified directed s?arJi date struc- 
ture wiu other records of said s 60 
graph data structure; and 
said directed graph retrieving means m rt ndmg means 
for hmitmg retrieval of said additional rows of 
data, when retrieving a sp eci fi ed dir ec te d graph 
data structure in accordance with a query incrucV 65 
mg retrieval limiting criteria, to thoae of asid acV^ 
tWwfl wwt of data thai are uofinected to said spect- 
fied at least one row of data by a sequence of refer- 



in each application process, 1 
program that utilizes directed 
in a corresponding application specified data fcr- 
«t^ : **r*i directed graph data structure mclnd- 
iag one or more r ecords of data interconnected by 
pointers, each record compo s ed of one or more 
data fr r^f** having respective sp ecified data 



types; 



queries to said 
trievmg and 
structures in 

_ directed graph 
from any one of said ap p licati o n 
- said 



for 
directed 



to said 
di- 



rected graph data structures from the application 
specific data format utilised by said one of said 



ate data 



from said database server to any oneof said appli- 
cation processes, translating said transmitted di- 
rected graph data structures from said predefined 
intermediate data format into the arjplication spe- 
cific data format utilized by said one of aaid appli- 



in said database server, defining a < 
each of a plurality of tablet in said < 
said database table having a plurality of rows and a 
tptrififnt rammer of columns, w herein each row of 
said database table stores daU values m each of said 
columns of said database table; said schema denot- 
ing a data type for each column of data values 
stored in said database table, each denoted data 
type being selected from a set of predefined data 
types including a reference data type; type; 

each non-empty data value stored in a reference data 
type column comprising a reference to a row of 
one of said tables in said database; 

fied directed graph data stmcturcs 
specified tables m aaid databn 
queries received from one of said application pro- 
ceases; said storing and retrieving steps including: 
receiving from one of said applic at i o n proce ss es a 
data storage query that includes a ap ec i fir d di- 
rected graph data structure in 
mtermediate data format, and : 
cord of rand received directed r^aph data 1 
tare m a distinct row of a reapectiveostt of said 
database tables, said record rsorm^ 
mgrtoriiigraudd^clernentso 
in cwespondiag columns of said one respective 
database table and storing references, each refer- 
encc ixMierportding to one of said porntfrs that 
interconnect said each record to oAer records of 
said specified directed graph data structure, m 
corresponding ones of said reference data type 
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5,201,046 
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10 



13 



column* of said one respective database table; 
and 

retrieving a specified directed graph data structure 
from said database in accordance with a single 
specified query received from one of said appli- 
cation processes, including retrieving in accor- 
dance with said specified query at feast one spec- 
ified row from at least one respective database 
table and then retrieving additional rows of data 
from respective ones of said database tables, said 
additional rows of data coinprismg rows of data 
that are referenced by r e feiences in other rows 
of data retrieved in accordance with said speci- 
fied query, converting said retrieved rows of 
data into a directed graph data structure in said 
predefined mtcrmediate data format, and trass - 
nritfing said retrieved directed graph data sliuc* 
tore to sasd onff application process. 
IX The control process of claim 11* 
said schema defining step tnc farting denoting in each 20 
said schema a table id entifier for each reference 
data type column, said table identifier specifying 
which database table is referenced by references in 
that re? h«ttMi* 

each said table in said database having an associated 25 
primary key comprising an ordered list of columns 
of said table whose values identify a panimlar row 
of said table; and 

each of said references comprising a primary key 
value of a row in the r e sp e cti ve database table 30 
specified by the schema for the table in which each 
said reference is stored* 

13. The control process of claim 11, wherein each 
diififtcd graph data structure m said intermediate data 
format includes rows of data values, each row of data 35 



values corre sp onding to a respective record of a corre- 
sponding directed graph data structure m the applica- 
tion specific data format utilized by one of said applica- 
tion processes, said rows of data values mcluding row 
pouters mteroonncctmg said rows of dita values, each 
row pointer cof icsi i aiidm g to a respective pointer in 
fajtf flOff iffpflfMywi g flimciteri graph dam stmctnue in said 
application specific data format. 

14. The control process of chum U, 

said query generating step mchxting the step of in- 
cluding in ones of said generated queries specified 
criteria for limiting retrieval of said addition^ rows 
of data. 

15, The control process of ctaini 1JU ^ ^ 

»r»Wwifl retrieval iwwfring criteria m ones of said 
generated queries, said retrieval limiting criteria 
denoting a maximum depth, said maximum depth 
comprising a f *in"* m number of pointers used m 
sequence to interconnect one or more top-level 
records of said specified directed gra|>h d^ta struc- 
ture with other records of said s p ec i fie d directed 
graph data atructure; and 
said step of retrieving a specified directed graph data 
atructure including limiting retrieval of said add> 
tional rows of data, when retrieving a specified 
directed graph data structure in accordance with a 
query nictating retrieval limiting criteria, to those 
of said additional rows of data that are co nne c ted 
to said specified at least one row of data by a se- 
quence of references no greater m number than said 
maximum number denoted by said retrieval bruit- 
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ABSTRACT 



An apparatus for g fawing data for use in ^Qfep^^^y ing diagrams 
comprises a i*nin"it« and a file server. Each diagram 
indndrs boxes and flow lines connecting the boxes. The 
software includes a database and a main program which is 

wrjtpftUfflMff faf *ftlTing f^riffyfiig ^jHflgyp^ff* rtata as WCM as 

perfecming predetermined operations on the data. In me 
database, data describing a box Is stared as an instance of a 
first software object class, data A^nMm^ a flow line is 
stored as an instance of a second software object class, 
general data relating to a diagram is stared as an instance of 
a third software object class, and data describing the location 
of each entity (box or flow line) on a diagram is stored as an 
instance of a fourth software object class. Each instance of 
the fourth software object class includes a pointer to the 
instance of the third software object class which contains 
general data for the diagram and also to a pointer to the 
instance of the first or second software object class which 
describe the entity. 

19 Claims, 2» Drawing Sheets 
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APPAKTUS AND METHOD FOR STORING ing unit, a memory, means far entedng data and a display 

DIAGRAM DATA unit, said memory containing a program for controlling the 

computer apparatus and which is arranged to: 

CROSS^^^CT TO RELATED ^ ^ for ^ m db9 ^^ m; 

Atruwuiuro 5 stare data represent^ ^ 
This application is a continuation of oar copending com- software object having a set of ataibotes which inclndes an 
monly assigned PCT application No. VCTK&95J0Q631 and identifier for the software object; 
it is also a co nt m natio iMn-part of our commonly assigned - store general data relating to an individual diagram as a 

application Set No. OS/263,221 filed Jul 21, 1994 now software object whose attributes indudc an identifier for the 

ABN. 10 software object; 

This invention relates to an apparatus for storing data for store datardating to the location of an indrvidual entity on 

use in displaying diagrams and also to a method of storing a diagram as a software object whose attributes include me 

diagram data and using the stored data for displaying location of the entity on the diagram and a pointer to me 

diagrams. J5 software object which describes the entity; 

When storing data for use in displaying diagrams, it is retrieve data describing the individual entities of a dia- 

d^snatile mat the data can borates^ gram; and 

efficient manner- In particular, it is desirable to be able to me the retrieved data for <fiybtyfa £ * «K» gr »m 

storcdata represent^ According to a mird aspect of mis invention, mere is 

diagram entity can be di^yed in niore u^ «tc diagram. 20 provided a method of operating a computer apparatus tor 

m EP-A-0 415 796 mere is described an objectroriented staring diagram data and using the stored data for displaying 

display system which allows the creation of graphic dia- rffagrem* , **r+> Ai*gnm ^ ■ ^ ■ ini iig » phwuKty c£ witiK*^ 

grams, this systeni, each diagram said method KVt i ip i 1 wng me steps oft 

and mere is no disclosure of using data representing a storing data dr*rrfhin g «»rh IiwHvIAmI rffrgm i n? 

particular diagram om^ m nro than or* diagram. 25 a software object having a set of a 

According to one aspect of this invention mere is pro- identifier for the object; 

vided a computer apparatus for storing data for use in storing general datarriatmg tn rarfi imtivMnni rti*gr»™ « g 

displaying diagrams, each diagram comprising a phm^ of a software object whose attributes include an identifier for 

cu titles, said ap p a r a t u s oomraising; the software object; 

means for entering data for use in displaying diagrams; 30 storing data relating to the location of each indfridual 

means for storing data describing an individual «H»gr*m entity of a diagram as a software object whose a t l ii fr^r ff 

entity as a software object having a set of aluJbutes which include the location of the entity on the diagram and a 

includes an identifier for the software object; pointer to the software object which describes the entity; 

means for storing general data relating to an individual 35 retrieving data d escribing .the indrvidnal entities of a 

diagram as a software object whose attributes include an diagram; and 

identifier for the Software Object; using thft rrfrirwH Artn far *Kyl»y m g * rtiagmm 

means for storing data relating to the location of an This iiivention will now be described in more detail, by 

individual entity on a diagram as a software object whose way of example, with reference to the accompanying draw- 

attributes include the location of the entity on the diagram 40 ings in which: 

and a pointer to the software-object which describes the FIG. 1 is a block diagram of an apparatus embcidymg this 

cutty; invention; 

means for retrieving data describrng the individual entities FIG. 2 is a block diagram showing the components of a 

of a diagram; and cotuputa farming part of the apparatus; 

means for using the retrieved data for displaying a dia- 45 FIG. 3 shows the components of the software used in the 

gram apparatus of FIG. 1; 

The present invention provides the advantage mat data FIG. 4 is a diagram illustrating some of the components 

describing a particular diagram entity can be used in dis- of an alarm management system for a teleeoinnnudcations 

playing mat diagram entity in more than one diagram. network which are present on a reticular day; 

The entities may include graphical shapes and flow lines 50 FIG. 5 is a flow chart of a routine STORE formingpartof 

connectiag the graphical shapes together. the main program of the apparatus of FIG. 1; 

When the enffiesiiicta FIG. 4 including FIGS* 6a and €b is a flow chart of a 

thft patphfrftl «b*p« ftytirr, data ^fiffriHng an routine RETRIEVE used in the main program; 

entity in me form of a graphical shape may be stored as a 55 FH5. 7 is a diagram showing the network management 

software object belonging to a software object class for centre together with four alarm collection centres which 

graphical shapes, and data descrifcdng an ein^ U the ftsm belong to the alann management system of FEG. 4; 

of a flow line may be stored as a software object belonging FIG. 8 *~-wfr. g FIGS. 8a and 8& is a flow chart of a 

to a software object class for flow lines whose a ttri bute s routine UNK forming part of u^ mam program; 

inemdear^ofrxinterswhi^ ^ Pifl + i« * A^grm nfth* »w» iMM prnwif «y* m ^ 

two software objects which descry respe FIG. 4 and generally similar m layout to uw diagram <rfFK5. 

at one end and the entity at the ouier end of the flow line. 4 bm showing fl^ components which are 

The apparatus may includes means for operating on the date; 

retrieved data in a predetermined manner to produce a FIG. If is a diagram formed by combining FIGS. 4 and 

desired diagram. 65 •; 

According to a second aspect of this invention, there is FIG. 11 including FIGS. Ua and 111? is a flow chart of a 

provided a computer apparatus including a central process- routine ADD forming part of the main program; 
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FIG. 12 is a flow chart of the alarm management system Referring now to FEQ. 4, mere is shown a diagram 
of FKj. 4 and generally similar to FIG. 4 but showing the illustrating same of the ccmponents of an alarm manage- 
compooents which are present at a date between the dates of meat system for a teleconwnnirications network which are 
the diagrams of FIGS. 4 and 9; present at a certain date. In the present example, these 

FIG. 13 including FIGS. 13d and 13b is a flow chart of a s components compose switches A, B, C, alarm collection 
routuielNrraRPOIJUEfom^ centre A, repair team A and a network ma n agement centre. 

FIG. 14 is a flow chart of a routine UST forming part of In FIG. 4 ^ "^P? 1 ^^ ^^^^^^l^ 
die main nrocram: boxes 4# to 45. Bach of these boxes is labelled with text 

uicmawpnigRuu, which provides information, such as the name, about the 

PTOSIS is a diagram* SipoE^^ 
structure of a company; 10 5#, 51, 52, each of the switches A, B, C sends alarms to the 

FK3. 16ilhistiateshowstcaeddatamayte alarm collection centre A. As iOnstrated by flow lines 53, 54, 

scenarios; the alarm collection centre A send 

FIG. 17 is aflowcl^c^arosnlne COPY which may jind the nf^nrirman y^ matnL Each of the flow fines 

part of me main program; 5* to 54 has a scarce and a desthi^ 

FIG. 18 is a flow chart of a routine PROMOTE which may 15 at the box which represents the component where infoana- 
fbrm part of the main program; tkm in the form of reports or alarms originates and the 

PIG. 19 illustrates the mapping between two diagrams destination is connected to the box which represents the 
tT wiHtring » w^i wmM ctmrhiTRifi twn Afffarent drnimins: component to whfch me information is delivered. Bach of 
and the flow lines has an arrow at its destination. As may be 

FIG. 2f including FIGS. 29a and 2tfr is a flow chart of a 20 observed, each of the flew lines is provided with text 
routine MAP which may form part of the main program. ("reports* or "alamO indicating to of the mforma- 

ItoemngnowtoHai, there is sh * 2"^. _ 4 rAS ^ 

for storms data far use in displaying diagrams. Hie appa- The boxes 4» to 45 belong to one type of diagram entity 
ratustt! ^nprfses three general purpose computers or „ while the flow lines 5* to 54 belong to another type of 
Y^rkrrtTiti-m 11, V* ~mtt»"*~* *y » r^m^nmr^nn itnv diagram entity. 

14 to a file server 15. The file server 15 functions as a The apparatus 1A operates in what is known as an object- 
r*ntr»iia^ ctnf» far »n ttwwt pwnpitmi 1 1 r 11, 13 Mid oriented environment In this enviroime i^ ate 
data for storage may be entered eimer at one of the com- cal real woridc^jecte are iiwdcllcdD^ 
peters 11,12, 13 or dkecfly into the file server By rKovkiing „ real wodd objects may be divided into object types. For 
three computers 11, 12, 13, three people may use fee example, me diagram boxes 44 to 45 belong to one type of 
apparatus simultaneously and access the data stored in the real wodd object and the diagram flow lines 50 to 54 
file server 15. However, where it is required that onfy one belonging to another type of real wodd otgectlbe software 
person shem^ be able to use the apparar^ iinplementatkm of an object type is known as an object 

it is sufficient to provide only one computer and the appa- „ class. A particular example of a software object class is 
rams will be described below with reference to only com- known as instance of the object class or, more simply, as an 
puterll. object Each software object class has a set of attributes, m 

The compoter 11 is of coiiventional construction audits theca»of aniiistaiicecf anobje^ 
main components are shown in FS3. 2. Hiese components vahies which collect^ 
mchidealn^l>,ateybo^ 

screen 21, a central pcocessiiig umt (O^ 22, a read four software object classes and ^f^l^^^S^ 

memory (ROM) 23, and a random access memory (RAM) INTERFACE, DIAGRAM and COOTEOT. The attxfcutes 
24. m operation progranis awl d^ *ese software classes are listed to Tables 1 to 4 below 

file server 15 into RAM 24. these tables will now be described in tunLTte attributes 

Referring now to FIG. 3, there are shown the components ^ for the object class AFFIICAITON are shown in Table 1 
of me software or programs used in the apparatus 10. These below: 
components comprise a graphical user interface (GUI) 3#, a 
main program 31, an interface 32 and a database manage- 
ment system 33. GUI 3t is formed from the two software 
packages AIDA and MASAI available from Hog Limited of 50 
the Surrey Technology Centre, 40 Occam Road, Guildford, 
GU2 5YH, England. As the construction of GUIs is well 
known to those skffled in the art, GUI 3t will not be 
described in further detail. 

The database management system 30 is me well known 55 
Oracle Database Management System. The main program 
3 1 com prises routines STORE, RETRIEVE, LINK, ADD, 
INTERPOLATE and UST which are described in detail The object class APPLICAITON is used to describe a 
below. In the present example, the main program 31 is diagram cutty m the fbm of a bc^ 
written m the progrijmninglangua^ 60 of the object class AFfUCATKKN, the attributes are set as 

functions as an interface between the main program 31 follows. ID is a unique identifier for me entity. NAMB is 
written in UGF and the Oracle Database inanagement sys- bom the name of the real world object represented by the 
tern 33. The interface 32 is the software package Asuuell box and also the text appearing inside the box. STAKT- 
available from Dog Limited. DATE and END-DATE together dffiM the fjeriod of validity 

The software components shown in FIG. 3 are stored in 65 or existence of the real wodd object represented by me box. 
the file server 15 and may be loaded into the computer 11 VIEWER gives the security level required by a viewer or 
when it is desired to use the apparatus. user to see or edit a diagram which incl u des the box. 



TABLE 1 





at dbiect chare APHJCATKKf 


Attribute Dmciytm 


n> 


qob^dd identifier Moe cottQf 


NAMB 




STAKX-DATE 


start cfaflD cf entity 


END-DATE 




VIEWER 
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Id the present example, the object class APPLICATION is 
the only object class for describing a graphical shape. More 
generally, there may be other object classes fcr omer ^ariii- 
cal shapes such as circles and ellipses. Each object class may 
also be associated with a certain type of data, for example 
data relating to a monitoring system, a group of people or a 
database. If desired, the graphical shape assigned to a 
particular class may be changed by the user. 

The attributes for me object class INTERFACE are shown 
below in Table 2. 

TABLE 2 



TABLE 4-continued 



10 





Nunc of object cbsc Cp^TEOT 


Attribute 




BOX-TVPB 


typo of tax 


UNB-TYFB 


typo of fioo 


VEWJBR 


sucuuty cttegory for tjdwu 


DIMGKA&UD 




CLASS-ID 


poharj to object cbx of cdity 


ENHTY4D 


posDasr a^ vd^^dd idofltffleff of CBtltjf 



Smoc at object chtx. JHasiwACB 



ID 

NAMB 
VIEWER 

SOPRCRCXASS4D 
SOURCBBNTnYjD 
SBSPCLASSJD 
DBSTSKTirVID 



* of entity 



i of entity it eoQcco of tine 
i of entity nt 



15 



20 



An instance of INTERFACE describes a diagram mtfty jp 
me form of a flow line. For each msturecf this cJjcct class, 
me attributes are set as follows. ID and VIEWER are set in 
a similar manner to the ccoesponding attribute for an 
instance of APPLICATION. NAMB is set to the text which 
appears on the flow line. SOURCE-CLASS-ID and 
SOURCE-ENITXY-ID are set to the name of the class and 
me Mwittflw for me fa«Hmr* of mat dass for the <H* grwm 
entity which appears at the source of fee flow line. In the 
present cramrdf., the class is always APPLICATION but, 
more generally, flow fines could be connected to diagram 
entities of other classes for other graphical shapes such as 
circles or ellipses. DEST-CLASS-ID and DEST-ENTTTY-ID 
give the name of the dass and the irkntifirr far the instance 
of that class for the diagram entity at the destination of the 
now line. 

Tne attributes for the dass DIAGRAM are grram Table 
3 below. 



35 



40 



TABLE 3 



Hmm of object cW DIAGRAM 
Dcacnptro 



NAME 

VIEW-DA TE 

VIEWER 



Each instance of DIAGRAM provides general data relat- 
ing to a particular diagram. A description of the attributes is 
set out clearly in Table 3. 

The attributes for the object class CONTENT are set out 
below in Table 4. 



TABLE 4 



Attribute 



ID 

X-COORD 
YCOORD 



htentifirc for flue eotily on (bo 
of fine entity on tfaer 
of fca cotky on the 



Bach instance of CONTENT gives me location and other 
details of an entity of a diagram on that diagram. Thus, 
X4X)ORDandY<XX)RDgr7emexandyc^^ 
the entity on the diagram. In the present example, the entity 
can be only a box or a flow line, ff it is a box, BOX-TYPE 
describes the type of box. For example, the box may be 
rectangular with straight sides or rectangular with curved 
sides. UNB-TYIE describes the type of line, for example 
thick or mm, used to draw me box or the flow line. 
DIAGRAM-ID gives the unique iaentifier for an instance of 
DIAGRAM which contains general data relating to die 
diagram on which this entity is present CLASS-ID and 
ENTITY-ID together define the instance of the object dass 
which describes this entity. Inns, if the entity is a box, 
OJ^SS-roisscttoAITUC^O 
CLASS-ID is st* to INTERFACE. 

The routine STORE is used for storing data for subse- 
quent use in displaying a diagram. The flew chart for this 
routine is shown in FIG. 5 and Ate flow chart whl be 
de s c rib ed with reference to storing the diagram of FIG. 4. 

In a step SI, general data for me diagram is entered and 
stored as an instance of DIAGRAM. 

Then, in a step S2, data describing one of me boxes 4t to 
45, for example box 44, is entered and stored as an instance 

QfAPPIJPATinTf. Tw a gfrpK^ At* Aatrrihing Irwtin^ 

of the box and omer associated data is entered and stored as 
an instance of CONTENT. Steps S2 and S3 are then repeated 
until an instance of APPUCATH3N and an instance of 
CONTENT have been created for each of the boxes 4t to 45. 

In a step S4, data is entered which describes one of the 
flow lines, for ex ample flow line 5#, and stored as an 
instance of INTERFACE. Then in a step S5, data describing 
the location of the flow line and omer associated data is 
stored as an instance of CONTENT. Steps S4 and S5 are 
repeated unbl an instance of INTERFACE and an instance 
of CONTENT has been created for each of the flow lines 5t 

50 to5 * 

Where data is being stored for a whole set cf diagrams, it 
is possible that some of the boxes and flow Hnes may appear 
in more than oae diagram. Where mis is the case, far each 
box or flow line which is present in more than one diagram, 
55 it is necess ary to create only one instance of APTUCXnON 
or INTERFACE. If the data for a radicular instance of 
APPLICATION or INTERFACE is subsequently updated, 
this is effective for all diagrams which inclnde this instance. 
The routine RETRIEVB is used for retrieving data for 
60 displaying a diagram. The flow chart for mis routine is 
shown in FIG. f and this will now be described with 
reference to the diagram of FIG. 4. 

mastepS20,theidentih^fbrfa 
relating to die diagram of FIG. 4 is entered. Then, in a step 
S21, the instance of DIAGRAM is retrieved. 

In a step S22, an instance of CONTENT is retrieved 
which points to the instance of DIAGRAM retrieved in step 



45 



65 
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S2L The instance of CONTENT retrieved in S22 points to Id step S29, a user may also d elete o r add instances of 

an instance of APPUC^^ CONTENT, APPLICATION, INTERFACE and DIA- 

instance of APPLK^OTON or INTERFACE is retrieved. In GRAM. 

a step S24, a check is made to determine if there are any Each of toe classes APPLICATION, INTERFA CE, DIA- 

more instances of CONTENT. Steps S22 and S23 are 5 GRAM and CONTENT includes the attribute VIEWER 

repeated for each remaining instance of CONTENT which which is used to specify the security of the viewer or user, 

points to the instance of DIAGRAM retrieved in step S21 in the present example, me same security category is used 

and for the associated instance of APPLICATION or for bom viewing and edniiig.Tr^ 

INTERFACE. security level to view a diagram, be may also edit the 

At this poiiu^ executing 10 diagram. By way of modification, there may be separate 

instances of CONTENT, APPLICATION and INTERFACE security categories for viewing and editing. This would be 

for the boxes 4t to 45 and flow hues 59 to 54 will be achieved by providing two attributes in each class for 

retrieved. security categories, one for viewing and one for editing. 

Each user of the apparatus has an associated security Where there are separate security categories for viewing or 

leveL Ik security level wffl »miialxy be allocated to each 13 editing, a user may be given authority to view a diagram 

ttsrr by the i~r*"n f«pnn«lMi» m^mging thft «rp«witiiR. without being given authority to edit it 

m a step S2S, a check is made to determine if the user has When the present invention is used in a windowing 

an security level to view the rfj p gnwi This is environment, two or more diagrams may be displayed 

achieved by cc^uing the user's security level with the simutta ncousry on screen 2L Also specific diagram entities 

value of VIEWER for each instance of APPUCAITON, 20 may be dragged by using mouse 19 from one diagram to 

INTERFACE, DIAGRAM and CONTENT which has been another. When a diagram entity is 

retrieved. If any one of these instances requires a security to another; it may be deleted from me first diagram and 

level greater man mat possessed by the user, the user is added to the second di ag r a m . Alternatively, the diagram 

Aw»rf access to the diagram. Tins is achieved by putting a entity may be copied so that it remains in the first diagram 

suitable caption onto the display screen in a step S26 and 25 and is added to me second diagram. This is achieved by 

men tcrmuiating execution of the routine, clearing and deleting instances of CONTENT as appropri- 

2f the user has an adequate security level, in a step S27, ate. 

me diagram is displayed using the data which has been When a diagram entity is dragged from one diagram to 

retrieved. another, the manner in which it is displayed may change. 

In a step S28, the user is asked if he wishes to edit the 30 Thus, the shape, colour and scale of a diagram entity may 

/ti T i» y ~ifti> £r »m Tf th*> n*rr indicate* ttmt he dnd not wish change when it is dragged from oaccUagiamtoancrthetThis 

toedftlhedif^ayrdrtMgn^ to achieved by provm^ a set of display attributes for e*ch 

iiser indicates m step S28 that hew class of diagram entity and providing values for mese 

diagram the diagram is edi^ attributes for each instance of DIAGRAM- Uma, the display 

th^n tprmtiwti^ Thft pmcerfiim c£ step S29 far editing the athihrfcs cotddittc^ 

diagram wffl now be described. the colour in which an entity is displayed. Thus, for a 

In step S29, the user may edit particular instance of APPLICATION, the attribute 

retrieved in step 21, any of the instances of CONTENT COLOUR could be set to a value red for one instance of 

retrieved instepS22 and any tf me iiwtaices of AFH^ ^ DIAGRAM and to a value green for another instance of 

CATION or INTERFACE retrieved in step S2X The user DIAGRAM. 

may edit any of these instances by displaying the attributes The ability to display two or more diagrams smnmv 

and their values and then <*""»g "* c the attrib ute value by neoraty and to drag diagram entities from one diagr a m to 

iisiitg the keyboard 2#.Ahern^ another may be achieved by using the following software: 

may edit an instance by positioning a pointer over the ^ the Solaris operating system from SUN Microsystems Ltd, 

relevant diagram entity with the aid of mouse 19. The user 31-41 Pembroke Broadway, Camberiey, Surrey, GU15 

then clicks a button on the mouse and this causes an edit 3XD, together with the software package MASAI and 

menu to be displayed. The user then edits the relevant Lelisp from Bog limited, Surrey Technology Centre, 40 

instance by following the instructions on me edit menu. Occam Road, Gtrikiford, GU2 5YH. 

When editing the instance of DIAGRAM retrieved in step ^ When retrieving the data contained in the software 

S21, the user might change the security category of the objects, it is retrieved from the file server 15 and stored in 

viewer or the name of the anagram. RAM 24 of computer 1L 

When editing one of the instances of CX)NTENT retrieved Referring back to FIG. 4, this figure shows the box 45 

in step S22, the user might change its location by altering the connected by flow line 54 to box 43. In other diagrams 

values for its x and y co-ordinates. The user could also 55 stored in the file server 15, mere may be other boxes 

change the entity (box or flow-line) which is displayed by connected by other flow lines to the box 45. The routine 

changing the pointer for the diagram entity. The user could LINK is capable of finding these omer boxes and flow Ito 

also transfer the displayed entity to another diagram by and generating a diagram which shows all the boxes and 

altering the pointer for the diagram identifier. flow lines connected to box 45. An sample of a diagram 

when fritting nnft of the intfancr* of AFFPCATIQN or 60 whkh may be produced by the routine LINK is shown in 

INTERFACE retrieved in step S23, the user might change its FIG. 7. 

name. In the case of an instance of INTERFACE, the user FIG. 7 shows box 43 connected by flow line 54 to box 45. 

could change the identifier for the entity at its source or the TOs Morniation is, of course, present on FIG. 4. FIG. 7 also 

j fentjfl gy for the entity at its destination. shows boxes 6t, 61, 62 connected by flow lines 63, 64, 65 

ff an instance of APPLICATION or INTERFACE is 65 tor>ox45.Boxes6# t 61 and©repre«eirttrn« further alarm 

edited in step S29, the changes will be effective in all collection centres, namely, alarm coflection centres B,C and 

diagrams in which the instance is used. D. The flow chart for the routine LINK is shown in FIG. 8 
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and this flow chart will be described with reference to 9, arc shown in the diagram of FIG. It in a third manner, 

^Derating the diagram shown in FIG. 7. namely with chain dotted lines. On a colour display screen, 

The user initially selects the box which is of interest In dashed and chain dotted lines of FIG. 10 may be 
the present example, box 45 is selected. Then, in a step S4#, replaced by three different cokranL 
the user enters the identifier for the instance of AFFLICA- 5 The operation of combining two diagrams is performed 
HON coirtaining data Awrihfng box 45. The user may ^ mc rootinc ADD and the flow chart for this routine is 

perform step S40 by typing m me c^^ shown in PIG. UL The flow chart of HQ. 11 wfll now be 

Alternatively, there may already be a diagram displayed on described with reference to FIGS. 4, 9 and 10. 

the screen which shows box 45 and the user then positions At trie start me nxitine, ma step S7tt^ 

a pointer over box 45 wim me aid of u^ mo 10 identifier for the instance of DIAGRAM which contains 

a buttc* to indicate thrt general date for the tto diagram. Thus, in Ifae present 

» — p#i ui^.j • ^i«wm^vT. example, the user enters the ldeiitifier for the instance of 

J»«**S41, the selected mstanaof AIMJCAnONis ^mAMfyt the diagram showninFK3.4. Tbeninastep 

rctncvc * L S71, this instance of DIAGRAM is retrieved. 

In a step S42, an instance of INTERFACE which In a step S72, the iiistances of CONTENT, AJETUCA- 

desa*e» a fiWKae connected to box 45 is retr^ 13 TION and INTERFACE for the first diagram are retrieved, 

present example, this may be the instance of INTERFACE Step S72 thus corresponds generally to steps S22andS23 

wfddi describes the flow shown in FIG. 6. 

of AFfUCAOW which describes tn^ Then, in a step S73, the user enters an idertrfier for the 

other end of the flow line is retrieved For example, if the insfamre rfDTAfig am for rtx» «^mnrf M*^™ Tn fr^h utr-pf 

instance of INTERFACE retrieved in step S42 describes 20 S70 and S73, the identifier can be entered either by keying 

flow fine 54, then the instance of APPLICATION which the characters which f can the identifier c«; if the diagrams 

describes box 43 is retrieved in step S43. In a step S44, a are already displayed, by positioning a pointer over me 

check is made to determine if there are any more instances diagram with the aid of moose If and dieting a burton 

of INTERFACE. Steps S4 2 and S43 are then repeated for all on mouse 19. 

ranaining mstances of INTERFACE whkh describe flow 25 fa steps S74andS75, the mstaiKe cf DL\(30^Maalthe 

fines connected to bo x 45 and the conesponding remaining inztmr** of myrPNT, ATTT JCATTON T^TERFACR 

instances of AFFUCAITDN which describe the boxes con- for the second diagram are ictrieved. m a step S7t\ a check 

nected to the other ends of these flow lines. is made to determine if the user has an adequate security 

mstepS45,acheckismadetodetermu^ level to view me boxes, flow lines and other dafe which will 

an a dequ a t e security level to view the boxes and flow lines be shown in the eventual diagram Thus step S76 corre- 

wUcfa will be displayed. This step is similar to step S24 speeds generally to step S24 shown in FKJ. & If the user 

described with refercace to FIG. 6. If the user does not have . does not have an adequate security level, access is denied to 

an adequate security level, access is denied to him in a step him in a step S77. 

Stf* 35 In a step S7S, the diagram emiries which are present in 
ff the user has an adequate security level, in a step S47, both the first and second rffo grm* are found. Step S7S is 
nte retrieved iiistances ct^ performed as follows. For each instance of CONTENT for 
present example, there are four snrh Instances, In a step S48, th^ first ifagnm > ft u Arti-nmin+A if ***** » r^^^muHn^ 
the digram is formatted. This is ac^ instance of CONTENT for the second diagram which pohits 
selected box at the centre of the diagram and then position- ^ to the same instance of AITUCATTON or INTERFACE as 
ing the flow lines and boxes whkh are connected to the (he instance of CONTENT for the first diagram. The result- 
selected box at equal angular spacing* around the selected ing instances of CONTENT, APPLICATION and 3NTER- 
box. In the present example, as there are four boxes cod- FACE are then associated with each other. 
iiecte4 to me selected box, tr^ In a step S79, the diagram entities which are present in 
around the selected box. 45 both diagrams are displayed in the first manner mentioned 
In a step S49, the new diagram is displayed. above. Thus, at this stage, boxes 41 to 45 and flow lines 51 
m the routine LINK, the instances APPLICATION and to 54 are displayed as shown in FIG. It. 
INTERFACE retrieved in steps S41, S42 and S43 are In a stepStt, the diagram etith^ wiac± are present only 
retrieved from the file server 15 and loaded into RAM 24 of in the first diagram are found. In order to achieve this, for 
computer 11. Steps S45, S47, S4S and S49 are then per- jq each instance of CONTENT for the first diagram, it is 
formed with the data in RAM 24. determined if there is a corresponding instance of CON- 
FIG. 9 shows the alarm management system of FK}. 4 at TENT for the second diagram which points to the same 
a later date. At trte date shown mITO. 9, swn^ instance of APPLICATION or 1NTERR\CE as the instance 
exists and a new switch, namely switch D, has been added of CONTENT for the first diagram, there is no corrc- 
Ih FIG. 9, switch D is represented by box 70 and flow line 55 sponding instance of CONTENT for the second Hfa grwm, 
71 shows alarms being passed from switch D to alarm then the instance of CONTENT forme first dia^am relates 
collection centre A. to a * w *g r * m entity present only in the first ^gram. These 
The apparatus If is capable of ncwnhtnfng two <fi* gn"«» instances of CONTENT together with the cccresponding 
iepreseraingapacticulaTrealw^ inst a nc es of APPLICATION and INTERFACB are then 
alarm inan a ge Tfi f nt system of 13GS. 4 ai»d 9, at two different 60 associated together* 

dates. For example, it can combine the diagrams of FIGS. 4 Then, in a step S81, the diagram entities p r esent only in 

aad 9 to produce the diagram shown in FIG. 10. In FIG. It, the frrst diagram are displayed in the second maimer. Thus, 

the boxes and flow lines which are present in bom FIGS. 4 at this stage, box 40 and flow line 50 are added to the 

and 9 are shown in a first manner, namely by solid fines. Tlie displayed diagram. 

box 40 and flow line 50, which are present only in FIG. 4, 65 hi a step S82, the diagram entities which are present only 

are shown in a second inanner, namely by dashed lines. Tbe in the second diagram are found. This step is analogous to 

box 70 and the flow line 71, which are shown only in FIG. step S80. 
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Lastly, in a step S83, the entities present only in the Instances of CONTENT far the second diagram which 

second <n»gr»m are displayed in the third manner. Therefore, point to instances of APPLICATION not present in the first 

at this stage, box 7t and flow line 71 are added to the diagram are then examined in a similar manner, 

displayed diagram. For each instance of APPUCATTON which is on the list 

In steps S71,S72,S74 and S75, date is retiiCT^ 5 of entities which are not to be displayed, each instance of 

file server 15 and stored in RAM 24. Steps S76 to S83 are INTERFACE which describes a flow Hne connected to the 

men performed on data in RAM 24. Because these steps are box described by the instance of APPLICATION is found 

performed on data held in RAM 24, rather men in the file and also put on the list of entities winch are not to be 

server 15, these steps arc performed relatively quickly. disitayed. 

?Z W !!lT ,d ^ 10 mthernxse*c*am^^ 

and 9 to produce a new diagram in which the boxes and flow ^^^^w^A^^u^Tyi „f prn o_ tft 

lines are^epresented in three different ways, the two dia- Gandhi addition box 70 and flow hnejl of 9 are to 

grains may be kept separate, mth^ <fispiayed "> diagram entities arc excluded, 

the boxes and flow lines which are present in bom diagrams Then, in a step SIM, the dia&am entities present at the 

are shown in a first manner, for example by solid lines. ^ interpolation date are displayed. 

Boxes and flow lines which are present only in the first Referring now to FIG. 14, mere is shown the flow chart 

diagram are shown in the first diagram m a second manner, fafe routine LET. This rc^nlneis capaln^c#prodncinga 

for examriety dashed Httes^ list of afl the diamms which ccntain a selected box. 

r^ o^ in the second diagram are ^ se^oM j^c*^ ina step the user selects 

diagramman^^ teShte fa ^ ii«mace of AFFI* 

Where fik server IS contains data for two diagrams 20 ^^^a^^ 



arrangement, for exampte the alarm Tmnagement system of ^toTco mouse 19 with me mouse pointer over the 

FIG. 4, me apparatus If is capable of prwmcing a further V^^^ 

diagram showmg those enmio _ ™™ . M „ . . . _ 

present at a specified date which is betw 25 Next, m a step Sill, the routine finds each instance of 

two diagrams. Thus, the apparatus is able to iiiterpolate DIAGRAM which columns general date about a diagram 

betweentwo diagrams. FIG. 12 shows the result of inter- which i nch trt r * the selected bc^Tmsisacfaie^asfbtows. 

polatiM between HGS. 4 aitd»c*^ For each instance of DIAGRAM, all the instances cf COW- 

pr^entexamp^ TEOTwhichpc4i<tomeiiistana 

wmcharcFresemmITC.4and,m 30 B"h of these iiistances of COrTOiOT is .examined to 

and flow line 71 of FIG. 9. Thus, at the date of FIG. 12, determine if it pointsi to the instance of APPU^ONfe 

switch D has been added but switch A has not yet been me selected box. Tnen, ma step S112, a list is displayed of 



removed from me alarm management system. 



these instances of DIAGRAM. 



The routine INTERPOLATE is responsmte te mterpo- the user wishes to display a diagram corresponding to 

itm g between two diagrams and the flow chart for mis oneof the instances of DIAGRAM on the list, the user may 

routine in shown in FIG. 13. The flow chart of FIG. 13 will achieve this by using me routine RETRIEVE, 

now be described with reference to FIGS. 4, 9 and 1Z The diagram of F». 4 representing an alarm manj^ement 

After entering this rootine, in a set of steps S9t to S95 system is only one example of the type of diagram which 

omwc pftiifKng ta steps CT1 tn S7S shown in FIG. IL me date ^ may be stored in the apparatus It. FIG. 15 represents 

far the two diagrams is retrieved fircm the file server 15 and another type of diagram which may stored and this fignie 

loaded into RAM 24. Thus, in the present example, the date shows part of the structure of a company together with 

fccbomnGS.4and9isretrievedmth^ reporting lines. Thus, FIG. 14 shows the main board repre- 

steps are performed with the date in RAM 24. sented box !•©, department A represented by box ltl, 

mastepS96,c««espondingto „ sections A, B, C represcnted^^e^ lt2, 1», lt4, and me 

is made to determine if the user has an adequate security reporting lines represented by flow hues 196 to Its. 

level to view the retrieved diagram entities. If the user does In a development of this invention, the diagram data is 

not have an adequate security level, access is denied in a step partitioned into scenarios and the scenarios are arranged in 

S97. a hierarchical or parent-child structure. This development is 

Then, in a step S98, the user enters the date of interpo- » suitable for modelling an evolving structure. By way of 

latkm. m me present example, this wffl be the date of the exanmle, FIG. 16 shows how diagram data for modelling a 

diagram Shown in FIG. 12. ^*on»nmnmr»tini»g tvMrarfr may hft partitioned Into * par- 
Then, m a step S99, to aiagram eau^^ ^aano, namely a reference scenario, and three child 
at the date of interpolation are found. In order to achieve sctaarJos, namely development scenarios A, B, CThe 
this, for each instance of CONI^OT for the first diagram 55 whence scenario contains (hagram date for uie network as 
wmcbpoiitotoaninst^^ presently existing aad plan^ 

SIAKT-DAIB and END-DATE are ccanpared with the date contain diagram data f or pro posed developments to the 

infr^st™ Tf thft of inteipoiarion falls within the network, ff desired, m e mnnb er of levels in the hierarchy 

period covered by the values of CTAKT-DATB and END- may be increased, for example by creating child scenarios 

DATE, then bom the instance of CONTENT and the corrc- <o f<* development scenarios A, B and C 

sponding instance of APPLICATION are put on a list for Vim mis development, a user of me system opts to work 

display. in a single scenario. Each user has a personal access profile 

If the interpolation date does not fall within the period wmch d rtmrrin c * which scenarios he has permissions to 

covered by me valnes of START-DATE and END-DAIB, read or edit. The scenario he selects defines toe dto which 

men the instance of CONTENT and the corresponding 65 he can view or edit 

instance ofAFHJCAITON are put on a list cf entities which Each instance of AFTUCAITON, INTERFACE, DIA- 

are not to be displayed. GRAM and CONTEOT is owned by a single scenario. The 
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VIEWER attribute is modified to point to the owning In step SMI, the data for each instance in the chM 
scenario rather than an individaal user. Instances owned by scenario is used to replace the existing data for the oarre- 
the parent scenario can be viewed by the child scenario, bat sponding instance in the parent scenario. This is achieved by 
instances owned by the child scenario cannot be viewed by using the pointers in the instances in the child scenario 
fl ic par ent la addition, instances of APHJCATION and 5 which point to the corresponding instances in the parent 
IOTERFACE which are owned by the parent scenario may scenario. Hat* for n«g inspires in tfre rhild scenario is also 

be used as diagram entities in the child scenario. Tn rtrfa rag/» t added to the data contained in the parent scenario, 

the DIAGRAM and CONTENT instances are owned by the Deletion of instances in the child scenario is handled by 

child scenario, but ownership of the APPLICATION and marking the instances as DELETED, rather than physically 

INTERFACE instances remain with the parent scenario. 10 removing mem from the database. Consequently, if an 

TTie »tlifl«ite* rf an t'nrttnw» may fitly h» ~ft>H whflfit inat*nrr>. in deleted in fhft rhilA mbmt^ nSt «rwr»gpondmg 

working in its owning sceawio. However, an instaire owned instance in the parent scenario will be overwritten by an 

by the parent scenario may be modified in a chfld scenario instance marked as DELETED. This 'sort deletion' method 

by creating a copy of the instance which is owned by the ensures that deletion of the instance is made visible to aQ 

child scenario. Instances created or modified in the chfld i* «™-"»"™* wfrfrfr "E»frr* "q^nf Ihr fnfitan<T and gtvrs nffrm of 

scenario may men be promoted to the parent «<*"»ri«\ In these scenarios an opportunity to make any necessary 

Order to achieve this, routines COPY and PROMOTE axe rhangen Perinrfjrafly, the datahasr. i* fmtrgeA tn pwM^^ntly 

added to me main program 31. These two routines will now remove instances which have been marked as DELETED for 

be described. a significant period, e-g. 6 months* 

The routine COCT is used for copying diagram from 20 It is possible that there wfil be a conflict between data 

a parent scenario to a cmld scenario. Referring now to FIG. contained in the child scenario and data contained in the 

17, aiter entering the routine COPY, in a step S132 a check: parent sceiiariafoexamr^ 

is made to determine if the user wishes to copy the data far scenario to tbe parent scenario may result in a new diagram 

any of m^ diagrams owned by the parent scenario, ff the user entity in the child scenario overlapping with an crating 

does wish to copy data for one or more of the the diagrams 25 entity in me parent reerwrin. Any men conflicts are recorded 

in the parent scenario, mis is achieved in step S13& in step S141 for resolution in step S146. The routine 

In step S133, for each diagram selected by me user, data continues with step S14f after step S14L 

is copied fox the respective instance of DIAGRAM and all IF me user does not wish to fvomote me entire cmld 

instances of CONTENT which point to the cor^ instance scenario to the parent scenario, a check is made in step S142 

of DIAGRAM. Bach copied instance is given a new idea- to determine if the user wishes to pfuuwte the data for any 

tificr so mat a particoJar instance u of the diagrams of the child scenario to the pareiit scenario, 

only. In addition, each copied instance is given a pointer If the user does wish to promote any of the individual 

which points to the corresponding instance in the parent diagrams, mis is achieved in step S143. 

scenario. The new instances of CONTENT point to . m step S143, me dam me instance of DIAGRAM for 

instances of APPLICATION and INTERFACE which are 35 th* ^Wn-d dfrgfm, tngnw with ^ahb^i^ w^i- 

owned by the parent scenario. After step S132 or step $133, ated instances of APPOCATTON, INTERFACE and CON- 

me routine continues with step S134. TENT which are owned by the rfrfirf scenario are used to 

In step S134, a check is made to determine whether me replace the data for uttcorresp^ 

user wishe s to co py any mdrvidual instances of APPOCA- ^ scenario. Any confiicts are recorded tor resolution in step 

HON or INTERFACE from the parent scenario to the cmld S144. After step S142 or step S143, the routine continues 

scenario, ff the user does wish to copy any of these with step S144. 

instances, mis is achieved in step S135. In step S135, me In step S144, a check is made to detemoine if the user 

data for each selected instance is copied from the parent wishes to promote the Atti| for any indrvidual instances of 

scenario to the child scenario. Each copied instance is given ^ AITUBCATION or INTERFACE from the child scenario to 

a new identifier so that a particular instance is owned by one the pmn* waari n ff the "«rr does w*«" tnf*nmnt* ftV 

scenario only. In addition, each copied instance is given a for any of the indrvidual instances, mis is achieved in step 

pointer which points to the corresponding m*t*r** in the S146. 

parent scenario, m step SMS, me user may select me instances to be 

After step S134 or S135, the routine continues with step 5Q promoted from an index of instances. Alternatively, a dia- 

$136 in which the diagrams in the child scenario are edited. g mm from the etrfM «wnmn may he d?«pl*yrd gfmgft*- 

Ihis is achieved in the manner described with reference to neousry with the corresponding di*gr»m from the parent 

step S2& in FKj. 6. Although not shown, the useinayretnrn g^wn fl nyv Tn thin raw^ ffrf fndf ytdiwi tn*tm^*m *r*> p p»nn^ f rf 

tOStepsS133orS135 to COpy tmlherd^LgrairiS or instances hy dra gg in g me cnrogniindfiig dia gram ent fflen with the aid 

if this is necessary during editing. 55 of mouse 13 from the ehild Aim^nm to the parent diagram. 

The routine PROMOTE is used for promoting diagram After step S144 or step SMS, the routine continues with 
data from a child scenario to a parent scenario. This rotrtine step S146 in which rnnfHt** are resolved. By way of 
may be used to promote all the data owned by the child example, in step S146, where a diagram entity in me child 
scenario to the parent scenario, or the data for selected scenario has been found to overlap a diy»» entity in the 
diagrams to the parent scenario, or the data for selected eo parent scenarios the conflict may be resolved by the user by 
instances to the parent scenario. This routine will now be deleting the diag ram entity in me parent scenario, 
described with reference to FIG. 18 . m a further development, the raxseminventkm can gen- 
After eTttrring the routine PROMOTE, in a step S14» a erate a diagram representing a real world structure in one 
check is made to determine if the iiser wishes to promote all domain ("the output domauT) from a diagram r e p re senti ng 
me data from the ctnld scenario to me parent scena 65 the same real world structure in another domain ("the input 
user does wish to transfer all the data, this is achieved in a domain"). By way of example, this further devdorHnent win 
stcpS141. be described with reference to a public telecommunications 
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network in which the input domain is the process domain 
and me output domain is the systems domain. FIG. 1* 
shows, by way of example, a diagram in its upper half which 
represents fault management for part of the network in the 
process domain. In its lower half, FIG. 19 shows me 
corresponding diagram in the systems domain. Hie dashed 
lines show the links or mappings between the components of 
the diagram in the process domain and the components of 
the diagram in the systems domain. 

In this farther development, the object class APPLICA- 
TION is used to describe diagram entities in the form of 
boxes which represent components of the telecoimminica- 
tions network in the systems flcm**"- With this former 
development, an additional object class PROCESS is used. 



to 



described above. INFUT_CLASS_JD is set to the name of 
one of me object classes ("the input object class") used to 
describe the diagram entities which represent the compo- 
nents of the modelled structure in the input domain. In the 
present example, the input object class is PROCESS. 
INFUT_JNCTAN€ajD is set to the value of me unique 
identifier for me instance ("the inpininstancO^ this object 
class. 

OlJTPUT__CLASS_JD is set to the name of one of me 
object classes ("the output object dass^ used to describe the 
diagram entities which iqaree n t the components of the 
modelled structure in the output domain, m the present 
example, the output object class is APPLICATION. 
OUlTOT_JNSIANCE_JD is set to the value of the unique 



The object class PROCESS is used to describe diagram 15 id ent i fier for the 



("the output instance") of mis 



entities in the form of boxes which represent components of 
ftlf> tHmmnfflmmfrfrtion* n*traHr in the process domain. The 
attributes far the object class PROCESS are shown m Table 
5 below: 



20 



TABLE 5 




Hnsm of oWect chsc PROCESS 


Attribute 




ID 


Uiimjuo falnurififj for entity 


NAME 


Nsxob of entity 


VIEWER 


Senility afegosy far tbwu 



Although in the present example mere is only a single 
object class for H^riMng diagram entities in each domain, 
in general there may be one or more object classes for 
describing diagram entities in each ^nm«n. 

The links between dia&am co m ponents in the input 
A wnnfa and diagram components in the output Aw ^ n are 
held in instances of an object clas s OONi mu MAR More 
specifically, each instance of <X>NTEXTMAPholds a link 
b et we en one diagram component in me input domain (for 
example, an instance of PROCESS) and one diagram com- 
ponent in the output domain (for example, an instance of 
APPLICATION). A diagram conn^entmtheinr^ domam 
may have more than one link to diagram components in me 
output domain. Far example, in FIG. 19, the diagram 
component named Problem Receptic* 
has a link to Alarm Control and a link to Load Fault Manager 
in the output domain. 

The attributes for the object class CONTEXT MAP are 
shown in FIG. 6 below. 

TABLB6 
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m 


UmqUD wVaniifWa for f»#a 




IHFUILjCLASSLJD 


Mnkv to ofcjcct ctan of dhgtam attmm 


IKPtTIJNSmNCSLJD 


MM HWIII 

Pouter to inikjUB jftcntrtn 


rfordogesm 


OUTPDT-Tf ASfLJD 


Itoiulv to object ckuBdt < 




OUTPUX-JNSIANCEJD 




rfcr<fiagnm 








coansxr 


Ouulraf In which m^pm 




VIEWER 


Seemly cMcyory fat yibi 


rer 



The attributes ID and VIEWER are set in a simflar manner 
to the corresponding attributes for the other classes 



object class. 

CONTEXT specifies the context in whkfa the rnapping 
occurs. For example, tor fault management in a public 
telecommunications network mere may be one mapping for 
fault mnttgmesrt in thtt tnmfr network and another mapping 

for fault management in the access net w ork. Where map- 
pings can occur only in a single context, the attribute 
CONTEXT is not needed. In the present example, it is 
assumed mat the mapping is in the trunk network. 

Referring now to HQ. 2t, there is shown a flow chart for 
a routine MAP which is used to generate * diagram in an 
output Awmfn from a H iff gr* ,Tt in an input domain. 

After entering the routine MAP t in a step S15# t the user 
enters the identifier for the instance of DIAGRAM which 
ffrtyrfty the in the input diagram. In the present 

*r«myl» thf* ner* *ntm tH* IAm*HW for thr. diagram Aoam 
in die upper half of FIG. 19. Then i n a step S152, the user 
enters the value of the amibutfrCONTEXT In the present 
manfittj me value indicates mat the context for mapping 
from the input <fanurin to the output d«m»fn is the trunk 
network. 

Next, in a step S153, data is retrieved for an instance of 
CONTENT which points to me instance of DIAGRAM 
retrieved in step S159. 

In step S154, it is determined if there are any instances of 
CONTEXT MAP for which the iinrt instance is the m^ 
found in step 1SX ff there are no such instances^ the instance 
found in step S153 is put on a list of unmapped instances in 
astepSlSS. 

If t in step S154, it is found mat there are instances of 
CONTEXT MAP for which me input instance is the instance 
retrieved in step S153, the routine goes from step SI54 to 
step S156. hi step S156, for each instance of CONTEXT 
30 MAP for which the input instance is the instance retrieved 
in step S153, the identifier and the class name for the 
corresponding output ?n«*"»T are retrieved. Thus, in the 
present example, one or more identifiers for the object class 
APPUCATION are retrieved. 

After step S155 or step S156, the routine continues with 
step S1S7. In this step, a check is made to fWrrmine if there 
are any more instances of CONTENT which point to the 
instance of DIAGRAM retrieved in step S15#. If there are 
any such fa^"**^ r the routine retains to step 153. If mere 
60 are no such instances, the routine continues with step S15&. 
By the time the lontine reaches step S158, in the present 
example there will have been retrieved a number of 
instances of APPUCAITON. Some of these instances may 
have been retrieved several times. In tine example s hown in 
FIG. If, providing all me relevant instances of CONinxi 
MAP exist, the instance of APPLICATION far the box 
labelled Central Fault Manager wfil have been retrieved 
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three times. In step S158, using an appropriate algorithm, 
these instances of APPLICATION arc used to generate the 
layout for a diagram in the output domain. A suitable 
diagram is described in an article entitled "Graph Drawing 
by Force Directed Placement**, Software Practice and 
Experience, Volume 21(11), pages 1129-1164, November 
199 L Ibis article is incorporated herein by reference. 

Next, in a step S159, the output domain diagram gener- 
ated in step S158 is displayed. However, if any unmapped 
instances have been found in step S154, the diagram will be 
fitcompletft 

Finally, in a step S16#, the list of n nmanaNi instances is 
displayed. W mm are any n nn« ji|iwtl jn<t»^~ f*y Bfffr qm 

then create appropriate instuices of CXJNTE^ MAP so mat 
me instances are no longer nnmapped. The raomwinay then 
be run again so as to obtain a complete diagram m the output 
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We claim: 

L A computer apparatus for storing data for use in 

displaying ^grwn^ t*mrh diagram ^Miyriffing W phimKty rf 20 

entities, said apparatus cctnprising: 

means for entering data for use in displaying diagrams; 

means for storing data describing an individual diagram 
entity as a software object having a set of a t tri b utes 
which includes an idenuto fee the scftwaxe 

means for storing general data relating to an individual 
diagram as a software object whose attributes include 
an identifier for me software object; 

means for storing data relating to the location of an 
individual entity on a diagram as a software object 
whose attributes include the location of the entity on 
the diagram and a pointer to me software object whkh 
oVjK'jfly.s the entity; 

mean* fnrT**ri«rying^jrtfl 4rffOri W ng Itwtivirfnal Mftfr* e£ 

a diagram; and 
means for using die retrieved data for displaying a dia- 
gram. 

Z An apparatus as in claim 1, in which in the means for 
storing data relating to the location of an indrvidual entity on 
a diagram as a software object, the attributes of the software 
object further indnde a pointer to me software object furm^ 
include a pointer to the software object containing general 
data relating to the diagram 

3. An apparatus as in claim 1, in which Ite entities mdnde 
graphical shapes and flow lines connecting the graphical 
shapes together. 

4. An apparatus as in claim 3, in which data describing an 
entity m the form of a graphs 

object belonging to a software object class for graphical 
shapes, and data describing an entity in the form of a flow 
Hoe is stored as a sofrware object belonging to a software 
object class for flow lines whore attributes indode a pw 
pointers which point to the identifiers of the two software 
objects which describe, respectively, the entity at one end 
and the entity at the other end of me flow tine. 

5. An apparatus as in claim 4, inctnding: 
first means for finding a software object h^™»g?ng to a 



describe the graphical shapes connected to the other 
ends of said flow Hues; 
said data displaying means being arranged to use the data 
contained in the software objects found by said first, 
second and third software object finding means to 
display the selected graphical shape together with the 
flow Hnes having one end cennectrd to the selected 
graphical shape and the graphical shapes connected to 
the other end of the flow Hnes. 

6. An a p paratu s as in claim 3, in which the <^irnmi^ of 
each software object which rep r esents a graphical shape 
indnde a jieriod of validity for the graphical shape, 

7. An apparatus as in claim 6> including: 
first means for finding soft ware cojects representing einl- 

ties which together for/a a first diagram selected by a 
user of the a p paratu s, said first diagram representing a 
particular physical or abstract arrangement on a first 
date; 

second means for finding software objects representing 
entities which together form a second dia gram selected 
by the user, said second di»gc»m representing said 

particular physical nr ahtdnr* imngMnwit rw* » 

date; and 

means for selecting those software objects from the 
software objects found by the first aad second software 
object finding means which re p r e sent entities vaHd on 
a date specified by the user, said specified data railing 
be twe en said first and second dates; and 
said data displaying means being arranged tn n*e ihe data 
cortained in software objects sekcted by the software 
object selecting means to display a diagram containing 
the entities which are valid on the specified date. 
Sw An a ppa ratus as in claim 1, ftwh«*h»g means for 
35 operating cm the retrieved data in a jr*Art*rmin*4 iMnnwtn 

produce a desired dia^am. 

9. An apparatus as in claim 1 including: 
first means for finding software objects representing enti- 
ties which together form a first diagram selected by a 
user of the apparatus; 
second means for finding software objects representing 

entities which together farm a xeennd diagram ******** 

by the user; 

third means for finding software objects representing 
entities which are present in bom the first and second 
diagrams; 

fourth means for finding software objects r epre s enting 

entities present only in the first diagram- and 
fifth means for finding sofrware objects representing 

entities present only in the second diagram; 
said data displaying means being arranged to display 
entities present in both the first and semnd diagram* in 
a first manner, entities present only in the ftrrfr diagram 
in a second maanrr, and entities present only in the 
second diagram in a third manner. 
1ft. An apparatu s as in claim t> in which for at least some 
of the software objects, the attributes of the software object 
iaclnoe the security level re 
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software object class for graphical shapes which 

describes a graphical shape selected a user of the «> to view a diagram inctading the entity represented by the 

W««tu»; sofrware object 

second means for finding each software object belonging 1L An apparatus as in claim 1, in which «rid dat a «mrmg 

to the software object class which re|ixsent8 a flow line means is arranged to partition the stored data into a set of 

having one end coiniccted to the selected graphical scenarios arranged in hierarchical tMtmw, said apparatus 

shape; and 45 further mdoding: 

means for copying data from a Inkier scenario to a 



third means for finding die software objects belonging to 
the software object class for g»pm>ai shapes which 



lower level scenario; and 
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means for promoting data from a lower level scenario to storing data draarihtng each individual diagram entity as 

a higher level scenario. a software object having a set of attributes which 

1Z An apparatus as in claim 11, including means fox includes an identifier for the 

raising datefrom a higher level scenario in a lower level stonnggeneral date relating to ^individual di^™ as 

s3owimo«rtcopX^^ to me lower lessee- 5 "* " 

na "?' . , . ^ . - „ . storing data relating to the location of each individual 

13. Anappara*isasmdarm^ * of a^a^nn as a software object whose 
aerating a diagram containing graphical shapes which nflrifrm include the location of the entity on the 
represent componeEts of a real world structure in one rffai gntm and a pointer to the software object which 
domain from a diagram containing graphical shapes which to ii+zrrih** the entity; 

represent the same real world structure in another domain. rgtrrevmg data describing indivkiml entities of a diagram: 

14. ACCTPpnttr a flNirW ^ farfiwting » ra#r«1 pmcewring 

Tmit 1 a rnemray, means for | *** tffr ' T> g data and a display unit; nring the retrieved data for displaying a diagram, 

said memory retaining a pmgram for coolrolling the com- 16. A method as in claim 15 la which in said step of 

puter apparatus and which is arranged to: 15 storing data restating to the location of each individual einiry 

receive data for use in displaying diagrams; of a diagram as a software object, the a ltrib n tr* of me 

_ _ ...... Atmtwrmvn «rt*Mr to . software object irjctude a pouter to the software object 

storedata rerceseatmg an ^^^^^ff^J coirtaiiiiiig general datt rdaft^ the diagram 

software object having a setof attfbutes which ^^lt^^ 

indndes an identifier far the software object; ^ ^^^^ and flew fines coMecting the graphical 

store general data relating to an individual diagram as a shapes toother, 

software object whose atrrihmes inchide an jdraitrfirr 18. Amethod as in claim 17, in which data describing an 

for me software object; entity m the form of a grapliicalsh^ 

store datarehding to the locate object belonging to a software object class far graphical 

a diagram as a urftware object whra M shapes and data describing an entity in the form of a flow 

the location of the eimty on tte line is stored as a software object belching to a software 

*1 . » . i » m c pointers which point to the Mentrfler of the two software 

retrkve data describing iwhvidual diagram entities of a describe, respectively, the entity at one end 

diagram;and and the entity at the other end ofmeflowfine. 

use me retrieval data for displaying a diagram. 30 19. A method as in claim 15, mcrodiag the step of 

15. A method of operating a computer apparatus for operating on the retrieved data ma predetermined manner to 
Btrwmg diagram Attn md raring the stored data for displaying produce a desired diagram. 

rfjagram^ ^ftrf^ <tt»gnim ixuttymheing a plnrality of entities 

said method comprising the steps of: * * * * * 
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ABSTRACT 



In a computer prototyping system, a design is identified from 
a collection of alternative designs, the identified design best 
satisfying a set of conceptual level design specifications. 
One of these alternative designs is selected and their char- 
acteristic optimized based on the conceptual level design 
specifications. The specifications are modified interactively 
using graphical interfaces for re-evaluating and 
re-otAi'miring the designs, Simulation of functional as well 
as geometrical properties of the design and its components 
are effected on a computer using graphical design browsers. 
The performance is analyzed against a set of design speci- 
fication and the user is allowed to interactively redesign by 
selecting one of the previous design operations through the 
graphical interfaces, 
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COMPUTERIZED PROTOTYPING SYSTEM (3) The decision model can incopcrate subsystems which 

EMPLOYING VIRTUAL SYSTEM DESIGN are designed through the VSDE of the invention as well as 

ENVTROMENT external designs and analyze the overall system. Also, it 

« * _ allows optimization of the system parameters, mcorporating 

BACKGROUND OF THE INVENTION 5 these subsystems. For this optimization, 

L Field of the Invention representation of the subsystems need not be known. This 

The pn^ invention is din^ to a computerized prt^ Zfs'^f^l^^! t ™*°° ma ^.<^ 

^gsystem conta^ a virtual systcn de!£ SS^S? ^^^^^^ 

environment, and more particularly, to a axnpoterized pro- tn jaw^auuiBi^ 

totyping system which allows a user through a paphical < 4) Sincc VSDE" of me invention integrates all me 

user interface to dynainica^ sta 8 es a typical system design, the design has complete 

ate its functions, and to automatically optimize the model flcxMit y m Bartering each stage in the design process, 

with the hefr of a knowledged based expert system. intermediate design parameters, and results of designs at 

2. Description of the Related Art 15 -™" fl ^^S^ lhC de ?^ tointo ^ 

~ yV _ ^ 15 the process at any stage, DKxHfy tte requirements or goals, 

The development of complex e ngineering systems ini- or modify the variables and constraints. 

caned conceptual design phase, im^^MfiTrfk tacocpo^ mto^ VSDE of the invention, along 

rec^rirenWsuch as coSTprofit, technkrfresoar^ mar- ■^p - ™"^* of tel^o^cal changes fa sobsystems 
J™.^-. ... ... „7!T^ *^T ^ . i^wvmi and conpoDents on the overall system can be ieadQv shoo- 

ag^S eSc^de^nT^ ^ ^ ^ ^ BRIEF DESCRIPTION OF THE DRAWINGS 

ft is estimated that about 80-90% of the product costs, ^ abawe omerfeatnres of me present invention will 

rngmreringrcqahxments andq beeome readily apparent to those skilled the art fremi the 

20-25% of the design phase. This makes the conceptual detailed description which follows and from the accompa- 

design phase particularly important. Though there is a well nyhwj drawings, in which: 
established industry providing sophisticated computet aided 30 FIG. 1 illustrates an overview cfte 

Design (CAD) tools for detailed design of engineering environment of the coujputeiized piututyping system of the 

systems, these tools are generally not suitable for the coo- present invention; 

ceptoal design phase. FKj. 2 illustrates compon^ 

SUMMARY OP THE INVENTION 35 T^T!* 

FIG. 3 shows a hierarchical representation of a conceptual 
Hie present invention is directed to a virtual system design process; 

d ^T in T^^l^^ dl ^ " <H B amzed FKJ.4sl>owscmnpoi^tf^ 
ccmputer-nnplemented approach to conceptual design of siipport system module; 

complex systems, ft provides a set ' A _ fl „ ^ . . ^ . 

analyzing the decisions at the conceptual design phase, 40 FK \ 5 * a 6x1101101121 du « nim <* a dca S 11 evaluation 
evaluation of candidate designs, higher level design optinn- process* 

zation and virtual system prototyping. The application of FI& 6 fflustrates a typical decision tree in me optimiza- 
VSDE is not restricted to the domain of engmeering design tion ^ decision support system module; 
analysis, ft can be effectively used in a variety of applies- FIG. 7 shows fuzzy membership functions of variables; 
tions such as management decision analysis, financial mar- 45 FIG. 8 illustrates the variable interdependency in the 
ket evaluations, logistics, data mining and data interpreta- analytical hierarchical process; 

tl0n * FIG. 9 shows a judgement matrix of the analytical bier- 

The computer-implemented virtual system design envi- arcmcal process- 

^-isxsss. -•«—•«-. ^^«™«« - „«. 

(1) Tbe VSDEof them vaiticai can be used for the entu^ pit 11 .a^JL .« ~ \1 ~* . rf . . . 

d^cydecf asysteni,startmgn^ . ^J^^l^^^ ^ anqxmiizatiop and deci- 

S ft can ea^analyze high level ^s^cS «*«™ ™* graphical user inter- 

against the performance requirements set forth by the 55 w 1* n»,,__, . . . . 

designer, by adding, deleting or changing variables, assod- ^ 12 mstntes ** <l*m»zation and decision support 

ated constraints and design objectives. As mentioned Sys ! em "^e user mterface for building decision trees, 

previously, commercially available computer aided design vanaWc strength and perfornuuK^ c*j<xtives; 

(CAD) tools do not deal with conceptual design stage of 13 shows an example of a decision tree in the 

system design. ^ optimization and decision su ppm t system ny*fnlf and the 

(2) War knowledge about a decision process can be evaluation results of six alternative designs; 
easOyinuapu ate dintheformof a knowledge based system 14. is a functional flowchart for the optimization 
(decision mnriiJ) TKft A>rfgnw «n m resting decision module; 

model or can create a new decision model during the FIG. 15 shows the architecture of a feedforward neural 

conceptual design process. The decision model in the VSDE 63 network; 

of the invention can be represented using fuzzy variables, FIG. 16 shows the iiKxaporation of noiiHnear functions in 

allowing representation of decision uncertainties. a decision model; 
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FIG. 17 shows an example of a graphical result of an design downselection and higher level design optimization 

optimization process; stages are a part of the conceptual design process, while the 

FIG. 18 is a functional flowchart of the virtual system virtual prototyping and virtml analysis stages 
design environment detailed design stage; d ^ afled design stages. In the conceptual design stages, 

FIG. 19 is a sample system hierarchical graph; 5 exact n^athei^ 

CT „ : * , . . . *V2 rmzedneed not be taiowii. The user can build a mc^ using 

HQ. Misasample siiteysteminforination database of the ^ dcdskm ^ pdad ^ 9 ^ ^ int ^ nti J^ 

system menrcmcal graph; between the variables defined as fuzzy variables, such as 

FIG. 21 illustrate a robot arm having two links and three mediums, high, very high etc. The conceptual design stage 

joints; 10 of VSDE is handled by a module called Optimization and 

FIG. 22 illustrates a system hierarchical graph of the robot Decision Support System (ODSS). ODSS allows the 

arm shown in FOG. 21; downselection of alternate designs and their high level 

FIG. 23 shows me subsystem information database cor- design optimization, 
responding to the system hierarchy grapfc shown in FIG. 22; The detailed design for the subsystems is done in the 

FIGS. 24(a) and 24(b) are representations of die hierar- 15 v* 1 * 1 *! prctctyping stage, where solutions are estimated for 

chical re£atk>n4up in ftw subsystems and connxments, FIG. a set of eolations descrihing the subsystems. As shown in 

24(a) being the two design and analysis path strpported by FIG. 2, in VSDB, these operations are a part of the Design 

me virtual system design eiivironii^ and Fia24(fr) being Environment (DE) module. The designs always need not be 

an internal representation of the system subsystem designs; performed inside me VSDB, me 

mi *>* .« o« mnctr^^ ~«^t* ^ 20 P 0 *** 1 ^ ccrainercial CAD systems. In the case of 

riu- 25 is an ilmstrauon shown me example of an 1,,,^. a~>x~- ~^—~+ :« i_- *_ 

iiuerface of the geometric design browser, functional design ta^mesubsyste^ can be 

i-wu^ « uic ipuim wsigii wuww; incorporated into VSDK ftfther fhi reigh t™*K-™H^ pwf. 

FIG. 26 shows the selection of one of the subassemblies sentations or through models. If periomiaiice of desi^at 

and correspond^ geeffl^ ^ ^ mV SDB does not meet the designer lequirem^ 

FIG. 27 is an example interface of a functional design 25 the designer can easily go back to one of the previous design 

browser; stages for modifying the decision model, the variable struo- 

FIG. 28 shows the selection of one of the subassemblies tme or the performance r c qui iementa. In the Virtual System 

and corresponding functional models; Analysis stage, the overall integrity of the subsystems are 

FIG. 29 illustrates design modification under the virtual Recked and analyzed, 

system design cirvironment; 30 Sta ^ 1: Evaluation of Design Alternatives 

FIG. 3# is a functional flowchart of the virtual system J^2^ a 'J 6 **** T t ^ < ^ ation 

design en virorm^ detail^ ^^h^^^ 

w zl „ ^ _ ^ , J , . J . . _ . a set of alternative designs may be known initially, and the 

FIG- 31 illustrates the interaction between the detailed pdrnary task will be to choose the most closely rnatdiina 

system design stage a^cotK^^dt^ga st^ during ^ c^^wrm respect to a set c^perfonn^ 

detailed system analysis operation; then modify ft to satisfy the performance reqmrements. 

FIG. 32 is a model dependency matrix for me example When the design process evolves from a very crude initial 

shown in FIG. 3*; design, the evaluation process may not be needed at the 

FIGS. 33(a) and 33(6) show snhmatrices for the model beginning. But, when the detailed design results in more 

dependency matrix; 40 than one design, the user may be needing to evaluate the 

FIG. 34 shows an example interface of the system anaty- designs and re^pmmze mem. In VSDE, such loop back 

sis stage; and between design modules is easily incorporated. 

FIG. 35 is a scliematic representing the general interre- ^/valuation ctf donatives and conceal 

lationshir* between 3*™*? ° °I ^, 3 ^^ m ^ 3 

prrtotyping system of the invention. 45 'f^f "^Sif ^P roccss - lta f f^T 

° J the designer to build sub-dividing the conceptual design 

DETAILED DESCRIPTION OF THE process. Each of these stages will be having a set of decision 

PREFERRED EMBODIMENTS frees. Though variables in decision trees inside a stage can 

be interconnected, interconnection bet ween variables in two 

Initially, attention is directed to FIG. 35 winch shows a so different stages is not permitted, 
schematic representation of the general int e rrel a tio n ships Each stage win be associated with a set of specification 
between the human user and the ccanprterized prototyping database, based up on which the decisions are made. The 
system of the invention, including the various components undarying decision process in ODSS consists of a Knowi- 
and associated inter fa ces. Stored in a computer RAM of the edge Based System in conjunction with coiistraint satisfac- 
prototyping system are graphic software code, design 55 tion algorithms and evaluation/optimization methods. Hie 
browsers code, constraint solver program code, printer and system consists of four ^dividual modules; a model base, a 
plotter drivers, optmrization algorithm code and knowledge knowledge base, a cc*straiiit solver ar*U set of o 
base system code. Further, a cc*nputer hard drive contains routines. The individual rnodules will be interring with 
&e requisite database, Inpit devices inctofe ^ each other and with the user through Graphical User Inter- 
mouse, and a printer and plotter may be plotter may be «, face (GUI). Tl» connwnents of the overaU system is shown 
provided in addition to the user interfece screen. in EKJ. 4. The flow-chart representation of the evaluation 

As shown in FIG. 1, the virtual system design environ- methodology is shown in KG. 5. 

ment of the present computerized prototyping system Knowledge Based System 

includes four major stages of operations: (a) Downselection The Knowledge Based System (KBS) consists of an 

of candidate designs; (b) Conceptual level design opomiza- 63 Artificial Intelligence ( AI) based representation of the deci- 

tion; (c) Virtual design and prototyping; and (d) Virtual sion hierarchy, dependencies of the variables at each of the 

analysis of the designed systems (FIG. 1). The candidate hierarchies and associated strengths of each variable. The 
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decision hierarchy is represented as a decision tree, and at 

any instant the characteristics of each of the nodes can be , ,J » » 

determined from the KBS and die input database. wp-^an Pi^ao ... p* ^<*± 

The designer either builds a KBS using the ODSS or loads 

a previously designed KBS into the ODSS. During the KBS 5 A consistency index CI can be represented by 
building, variables at each level and their interconnectioii 

strengths are provided through a text edit window. The K--n 

designer views the decision tree structure through the a= n _f — • 
graphical user interface and makes any necessary changes to 

the model, at any time during the design process. 10 _ . ^ , 

The user has the flexibffity to ad^crdelete any variable ^ ^oitsistency mdex Q is then compared wrm a 

atanylevdfcthehier^^ S^^SeTSisS a^al Se^in^ 

entire system WG.fdeta^ S^^^Tt^^^Z^TZ^ 

mthiscasc&erearctalevefc^ r^T^t^ ^S^^f i TZZSZ £ 

docs rx*assurr* airy restrict t « l?*** * A t modci i 13 acc f£ ted rf 

/^T^. « «T ♦ . /T uumwaw u m e consistency ratio CR is less thati or equal to 0.10. 

on the number of variables in each the levels. For coxnpkx Ca^^tsSvet ^ 

models and finer evaluations, the user expands the variables <^>n^raim server 

and associated stnrtures, and perf om^edsion process. , ^coj^sol^ 

m the decision tree shown in FIG. 6, there are four *> be satisfied in fee decision process. Tlie coiistaints can be 

subleveis of variables and seme of me £ two t^; recurred cwtstr^ 

iotemmiiected from other su^ 20 pc preferred cc^tramls can h^ 

level hierarchies are deeper than the other ones. A deeper far eMm P lc * 60111 to very high (see Zadeh, LA^ 

hierarchy corresponds to a finer decision modeL Such flex- Fazz y 8Cts » informaUm and Centre^ 1965, pp. 338-353). A 

ibitity in defining the interconnections and hierarchies result which satisfies all the required constraints can be 

allows ODSS to model complex decision and evaluation taken as an admissible one; which can be considered for a 

processes. 23 closer evaluation based upon the rjieferred set of constraints. 

Thft intM ym^^ftin n gtmngthg can twt jL<edgn «i in tftrrm nf In general, the constraint solver should be able to handle: 

■rnirariral vain** orfiiTay vwUMm Thn m ii n w j r*\ pin g ftfnr adding a variable, removing a variable, adding a constraint 

the strengths is between 0.0 and L0. The fuzzy strengm and removing a constraint. The system should re-evaluate 

corresponds to a set of membership functions defined in this itself in these cases. 

numerical range. The designer can choose the number of 30 The property of the constraint solver to handle adding/ 

variables defined in tins range depending on me refinement removing of variables and constraints is very important in 

needed. FIG. 7 shows a set of typical membership functions ODRS. Th* impKr^rmq ^ffrfirre trehiiri^ ?n s ub s y stems 

used in ODSS. as well as 00 the overaU system wfflb 

When numerical values are used for defining the variable variables and co ns tu unts . Any constraint solving algorithm 

strengths in the decision hierarchy, ODSS incorporates a 33 we develop or adopt should have this characteristics. Such 

scheme based on Analytical ffierarchy Process (ASF) (see an ability is also crucial in making the overall methodology 

?T ^f^f? making: rnodels and algorisms, Kriegcr very general to be used with design and downsekcttoo of 

Publishing, 1991.) for e s ta bl is h ing a set of consistent con- very wide range of cogir*erins systems, 

nectoon strengths. Model Database 

Analytic Hierarchy Process 40 Each of the decision stages in ODSS has an associated 

The Analytic Hierarchy Process (AHP) provides a con- model database. Model database consists of the specifica- 

vemcnt way to build the decision model for dcwiiselecnon tk>ns and functional details of the design alternatives under 

and op&mizat^ TTie model is built by ccmpa^ the consideration. Hie database information provided needs to 

variables in a level revise. In ^ *>Jf J£ V£ V3 be be insistent wim me ^ 

^^^^^^^"^^^^ 45 ODSS.thxc^meGUI^ 

rm ^ _ . . _ . database or load an existing database. The interfacing is 

The user assigns a set of panwise weighting for the Anw . 0 M ^ JiZL™ • • « T .*r 

variables as sr^below: Constocta3x3 rna^itheach *!£^%£^ 9 ***** CaS ^^l 

element in the matrix representing the relative weights ^""^J^JZ^uI^ deagner also proves die 
between me variabkpairs.1^ m f"^ 0 ^ * ^ *d**vOi*ta**m 

fftenmnber of variables to 50 ^ be used for converting the specifications into a cornmon 

take the product of the entries that row (h*) and take the ^ma^tL 

cccresrx)nding geometric mean P„ where P<=3^ . Utflity functions translate diverse input characteristics 

The ncnnaKzed value tftlrc intoacommciisc^Theraiigeof mility curve encompasses 

mariry or weight given to the r* alternative rVTl ixs. ^ °* acceptable or realistic alternatives. The trans- 

55 formed range in ODSS is O-1.0. The zero point for each 
p t utility curve indicates the level of performance which no 

ft" longer provides effective value to the system performance. 

^ Each of the input variables in the decision model is associ- 

ated with a utility curve. 
60 In principle, there can be two types of input variables in 
m me example of ^ a decision tree, a variable wrdchr^odx^pc^e effects for 

FK5. 9, Pj^'Vab, P^cJi, P^ITnc. The consistency of higher values, or a variable which prodiK« rjegative effects 
me hierarchical model constructed by the user, can be for higher values. For example, in the design of a motor 
checked by estimating a consistency index as follows. vehicle, power may be a positive variable while time for 

Consider an AHP judgement matrix with n rows and n 65 acceleration can be a negative variable, FIGS. l#(a) and 
columns. Let p, be the corresponding AHP priorities. Cat- 10(b) shows examples of utility functions for positive and 
culate the maximum eigen value of the matrix: negative variables. ODSS has a library of utility functions 
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and the designer can specify one of them for each of the learning from previous designs will not be difficult to 

database variables. incorporate. This feature is not currently employed in 

The Graphical User Interface ODSS, but wffl definitely an attoctrwiiopertytoaddoiiat 

The Graphical User Interface is an important coxapooent later stages of development 
of ODSS and VSDE. In using the VSDE, many of the 5 Decision Trees and Neural Networks 

flexibility comes from iiser-ftiendry GUIS. Mainly there are In ODSS, the architectural and operational similarities of 

three types of interfaces in ODSS. The front end where the neural networks and decision trees are exploited for the 

designer selects all the necessary settings for starting the system optimization applications. FIG. 15 shows a feedfor- 

design and evaluatioQ process; a set of text editor windows ward neural network architecture with one layer of hidden 
for building the decision niodeLvariabde hierarchy, database to neurons. In a typical feedforward neural network 

and specification of performance objective; a set of graphics architecture, the nodes between two layers are fully inter- 

panels to display rotermediate as well as final results. The connected. In the decision tree architectures used in ODSS, 

front end interface also allows loading and execution of nodes in different sub-levels (FIG. 6) need not be miry 

predefined examples and decision models. FIG. U shows intercoiuiected; though in a complex decision model the 
me front end interface of ODSS and FKj. 12 shows the text 15 number of interconnections may be high 

edit windows for dffintng variable hierarchy, strengths and In some of the decision processes, all the decision trees 

performance objectives. need not be interconnected to all the other trees. In such 

A sample set of decision trees in the first stage of cases, if the designer decided so, opomization of the indl- 

altemative evaluation is shown in FIG. 13. In this case one vidual decision trees and associated decision parameters can 
of the second level variables is shared by two trees. The 20 be done (when trees are interconnected, ODSS does not 

designer can scan through all the decision trees modeled in allow this option), 

me ODSS and can make changes in me model through the Deterministic Optimization Rocess 

GUIs for defining variable hierarchy. The sample results of In ODSS an adapted form of bakrxopagatioa algorithm 

an evaluation study is also shown in FIG. 13. In this case (see Riimeftart, D., Hinton, G n and VOTiams, R, Learning 
ODSS evaluated six different design alternatives against a 23 internal representations by error propagation, in Parallel 

set of designer specified criteria and ranked them m Distributed Processing, voL L, MIT Press, 1986) is used tor 

cal order. the optimization process. TVo different kinds of optimiza- 

Stage 2: Conceptual Level Design Or*imization tioo are possftlewjth me concepts set roth m ODSS. Bimer 

The second stage in VSDB consists of the optimization the optimization pm^i cm ryrimtr* th* wights a*g/v-jafrsfl 
module for design4o-reqinremeiit tasks. If the designer has 30 with each of the variables or it can optimize the value 

gone through the design evaluation process, he/she can pick associated with each of the variables, m the first case, the 

one of the design alternative and optimize the design vari- decision model gets optimized and in me second case it is 

ables against a set of perfornmce requirements the input variables which are getting optimized. Only the 

the designer can start with a crude set of design parameters second case is relevant for engineering design applications, 
and the decision model to obtam the optinuirrf set of design 35 But in applications where the decision model itself need to 

parameters. As in the case of evaluation of alternatives, the be optimised, the fa** rhflr^^ rin of nnftfl *n «imfa»tf rtn 

op timizatio n can be performed by splitting the whole pro- will be useful The designer can select this mode of opti- 

cess into different levels and optimizing each of them mization through the GUL 

separately. While evaluation of prototypes is a forward chain Let net, denote the summed output of a node L Then, 

operation, design optimization can be seen as a backward 40 net^WwonL 

chain operation which is more ^-^n than data-driven, where w tf iQe taercoiinection weight from node j of the 

The fon^onal flow chart of to^ <)ptimization process is lower lay* to the node i and out, is the oiitr^ of 1^ j. 

shown in FIG. 14. The designer loads a <iec^ A sigmoidal traiisf ormatioii^f{ ) to the summed output 

specifies the performance requirements into the system, results in: 
along with the specification database of the design to be 45 

optimized. As indicated before, the design can be one of the 1-©-* 

evaluated designs from the previous design stage or the =tf net*) = 
database corresponding to a crude design. The specification 

database is iterativdymodin^ „„„ . . . . . ^ ^ 

rithms inside ODSS. ODSS has twooptim^a^n^gorM^ so J^?. JSj^ 

buiUm; one based on determ^ eSS^ mterconiiecuon strengths are 
and the other one based stochastic optimization principles. 

One of tike amaue characteristics of the ODSS implemen- w^n+iy+wfay+AW^n+i) 
tation is the translation of its knowledge base as a neural 

network architecture during me optimization process. This 55 where 
allows ODSS to use neural network optimization algorithms 

in the design process. Such an implementation also allows AW ^ ,H " 1>=n ^ 

the ODSS to incorporate functional relationsh^ or models When ODSS is used for design parameter octirrrizaW 

of subsystems into the nigh level system optimization pro- the updating equations for the input variables are expressed 

cess. Exact mathematical form of these models need not be 60 as; 
known for the optimization process. These properties of 

ODSS and its use in subsequent system design stages is o^iy=o^nYAW^n¥i) 
explained later on. 

Another important cfiaracteristks of ODSS is the ahility where, 

of its decision model to learn over design examples. Since 65 ^ , lt « w 

the implementation of the KBS in ODSS is employed as a *^ 

decision tree and algoritmically treated as a neural network, where 
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Spfl'prO.Jfretd The probability P^n) is given by flic expression: 

for the output nodes and i 

fcranyajfctiaryM^ where A^n) is given by the ^relation: 

At each iteration, the parameters are updated as per the 

above set of equations. A/n)=Aot*4>i>l£fc) 

One of Che significant differences between the generally 1Q A _ . „ A „, v ^ , . , 

used neural network learning and the ODSS hm>lementation Aout^n) and AE(n) are the changes in the weight outbid the 

is the ability of ODSS to incorporate any transformation «ror measure B over the previous two iterations (for the first 

function at the nodes. Nonlinear functions can beincorpo- two iterations, P<(n) is ta ken as 0 5). In the expression for 

rated into the ODSS decision model by replacing the sig- P<W, T is a positive teunxaature mat detenmnes the effec- 

mokUdtiaiisfonnat^ 15 ^dOTiness in the system. VTilhn non-zero value for T, 

exann^e,consiteaiiofe^ ateoammtakes biased ranto waJks m me (hrection of 

in FIO. 1*. In this case f(.) is a function of variables x^ decreasing E. The optimization process starts with a large 

and x^x^ and *3 can be the i^ f^S^rLhni^ 

which case node N is in the input layer, or they can be the StoppingCritena for the Optimization Process 

of other nodes in the lower layer: « . 10 2°S| ^1 «■ 8 P cca ) r the irambcr tf itera- 

*n*»*m«A A^ Mn jciA, ( .«« M *, ^A.nitfc: i &oiis(mGlJty through whwhtte 

J^J^ ^f^STS. *!J^ to be cxmtineed crfce error toleranceln^ 

Sineatooon of the optonizatoi process compared to the mance objectives. ODSS monitors the effort betweesthe 

^^^^S^ ^ de^perf^ 

e exa ct func tional form of ft) need not be tawwn for the and the system performance, and Ifthfeia less ftanfme 

overall optimization process. K me detenninistic optimiza- 25 tolerance specified, me optimization process is stopped, 

fan prccess is used, the only re<n^^ Boor tolerance based stopping overrides iteration based 

is mat its derivative should exist and should be known, m stopping. Iteration based stopping is necessary, since in 

cases where f(.) and its derivative are unknown, the designer some cases the designer may be putting unattainable per- 

can choose the stochastic optimization process in ODSS fosmance specifications and there may not be a system 

through the Graphical User Interface. 30 desi'gnaMe for those specifications. In these cases, ODSS 

Stochastic Optimization Process stops the optimization process based on the number of 

The second optimization algorithm implemented in specified by the designee 

ODSS is called Alopex (see Umdknshnan, K. P., and Graphical User Interfaces CoriespoDoaiig to the Optmiiza- 

\fenugopaL, K. P., Alopex: a correlation based learning ^"f^ 8 „ _ *" 

algorithm f or feedforward and xecunent neural networks, as ^Jhe designer lists the performance specifications in the 

Neural Computation, voL 6, 1994, pp. 469-490). Alopex is «ht wmdow« the front end GUI If the 

tv. .i^rtJ^^Ju, 1 .2/^^^ ^"L " alternatives, the designer can choose one of me alternative 

^ t^t^f^^ It «^foroptm*i^ 

^^TT' ^ detoinodd, and the cfcoosinTtf the optiinizatioTa^orithm 

S3mc^^.The ^ 40 (determiiristic or stoc^ 

need not be calculated for updating the parameters. A endGUL The designer can observe the optimization process 
correlation measure between the change in weight and the through windows and visualize die optimized system char- 
global error change is estimated and the individual param- actenstks through the results window. FIG. 17 shows an 
eters are changed based on a probability index of going in example of the results display, 
the right direction of optiinization, so that the global enror 45 Sensitivity Analysis 

function is minimiz ed The sensitivity of each of the variables in the decision 

Consider a node i with an interconnection strength w-, model to the changes in system specifications can be easily 
from neuron J in the lower layer. The output of the node 1, calculated and displayed in ODSS. The designer can choose 
during the n iteration, is given by: one of the input variables and find its effect on the overall 

so performance requirements or any intermediate level deci- 
ixmny=EW i /inpa£*) sion model nodes, fixing all me other input variable values. 

The results are displayed on a graphics window in ODSS. 
Applying a transformation ft\) to mis results in Stage 3: Detailed Design 

The third stage in VSDE consists of the Detailed Design 
o*j(ji>^iKt4t)) 55 stage. This is a part of the Design Environment (DE). In this 

stage, subsystems and components of the system are 
During the n* iteration, output out, is updated as, designed and integrated into VSDE. FIG. 18 shows the 

functional flow graph of the detailed design stage. Hie 
oit/»)=«rt/i»-i>+^a) designer has the flexibility to design some of the compo- 

^ nents inside V£T>K itself nr H ran import PTtrmally A»«lgTw*l 
where 8/n) wffl have a small positive or negative step of size coinponents into it for integration. For internal design, the 
the following prob^ exact maAar^cal eo^ representing the subsystem 

being designed need to be known. 

)In VSDE, two different design and Integration are pos- 
65 modes of design can be chosen by the designer depending on 
the application in hand. In the geometry based design, the 
subsystem property of interest is the geoinetrical character- 
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istics.The subsystems may be represented as 2D or 3D CAD 
models and die design environment allows die designer to 
virtually integrate the components into subsystems, and the 
subsystems into the overall system. 

In the function based design, the p ropert y of importance 
is the functionalities of the subsystem and its components. 
This mode of operation in VSDE allows the designer to 
easily integrate subsystems such as electrical power supply, 
control systems, suspension etc. into the design environ- 
ment. In this case me integration is based on the function 
models or B&aJhemattcil equations representing the sub- 
systems or its components. 

In both the modes of operation, each of the subsystems are 
associated with a Subsystem Hierarchy Graph (SHG) and a 
Subsystem Information Database (SIDB). The Subsystem 
Hierarchy Graph dictries the hierarchy of subsystems and 
any changes in subsystems, components and their integra- 
tion need to be reflected through SHG. SIDB keeps a recced 
of the internrelan'onslups with other subsystems and associ- 
ated cojistraints. At any time during the design process, the 
designer can change the information database, subsystem 
models or functionalities and do the studies based on the 
new set of subsystems and functionalities. Also, the designer 
can study the effect of changes in each of the subsystems on 
me overall performance characteristics he/she has specified 
in ODSS during the Stage 1 or Stage 2 operation. 
System Hierarchy Graph 

During the detailed design stage, the subsystems and 
components of the subsystems are represented by the SHG. 
Each of the subsystems and its components are r eprese nte d 
in a hierarchy with each link representing the breakdown of 
the corresponding entity. Each rectangle in SHG corre- 
sponds to an entity and each of the rectangles connected to 
it from the lower level corresponds to the primitive entities 
associated with it For example, an entity car can have 
engine, chassis, wheels etc, as to primitives and at the next 
lower level engine may be having primitives such as casing, 
spark pings, fuel injection module, and valves. FIG. 19 
shows a simple SHG of a power distribution system repre- 
sented as a three level hierarchy. The user can define more 
levels in the hierarchy primitives for each of the entities, 
depending on the refinement in the model needed. 
Subsystem Information Database 

The Subsystem formation Database (SIDB) consists of 
a connection matrix relating the subsystems and components 
themselves. For example, let Power Distribution Circuits 
(PDC) module in FK3. 21 have a direct correspondence with 
the module Battery. The correspondence means, for effective 
functioning of PDC, Battery is a must and vice versa. Note 
that in the SHG this information is not reflected as inter- 
relationships between modules in the same level. SIDB 
helps in simulating the overall system by collectively con- 
sidering the subsystems and their interrelafionsbips. When 
VSDE is used for evaluating technology changes in sub- 
systems and components, such a database is essenttaLTech- 
nologkal advances in one of the subsystems need not 
translate to an overall i un ao vem ent on the systems, unless 
advances of same magnitude have happened with the other 
related subsystems and components. 

Far the example hierarchy in FIG. 19. the SIDB for the 
middle level will be of the form shown in FIG. 2#. Here, the 
entry (Battery, Wheel Drive) relates the importance of 
Battery for the function of Wheel Drive, and the entry 
(Wheel Drive Power Distribution Circuit) relates the impor- 
tance of Wheel Drive for the function of Pcwer Distribution 
Circuit Note that die matrix need not be symmetrical, since 
the relationships between subsystems or relationships 
between components need not be symmetricaL For example, 
(Battery, Wheel Drive) relationship may be High, while 
(Wheel Drive, Battery) relationship need not be High. 

The SIDB in the case of geometrical design and func- 
tional design will be different In the case of geometrical 
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design, SIDB contains information about the physical link- 
ing of subsystems and components. Hence the SIDB matrix 
in this case will not be having fuzzy entries such as Medium, 
Low etc The relationsmps will be expressed as yes or no, 
5 with the yes value indicated by a 1 and a no value indicated 
by a 0. Also in geometrical design, the SIDB matrix will be 
syTiun e* 1 ***^*! 

An example of SIDB in the case of geometry based design 
is given below. FK3. 21 shows a robot arm with two links, 
three joints and a set of fingers. The 

10 beof tefarmassbx>wnmFIG.22*SIDBpbysan 

role in applications like mis. m this case SHG does not 
convey information about the arrangement of the links; 
whether link 1 and link 2 are connected through joint 1 or 
joint 2; or whether the wrist is connected to joint 3 or joint 

15 2 etc A typical SIDB for tins design problem is shown in 
FEG. 23. Tne matrix elements are 1, if the corresponding 
(row, column) combination is physically coojiected and 0, if 
not 

In both feese samples, me SIDB is represented as a 
matrix wife the relationships between two entities repre- 

20 seated as a single variable or numerical value. In the present 
implementation, mis is done employing an array. More 
sophisticated inrokjiwilati on of SIDB may be needed to 
deal with more complex probkms. In such cases each of the 
relationships may be represented by a multiple element data 

23 structure. 

Geometry Based Design and Functtonal Design 

VSDE allows two types of system design and analysis, 
geometry based design and frmrtional design. In geometry 
based design, the physical characteristics of the system is 

30 taken into consideration. It is similar to a typical top-down 
design approach. The physical characteristics include size 
and shape. In this case, fee subsystems are the physically 
separable components of the system. The system can be 
represented as a 3D structure or 2D structure and VSDB 

35 allows incorporation externally d*rfgn«d components of 
these structures. The objective in this case is to evaluate the 
integration of subsystems and their components *nri visual- 
ize mem graphically. The subsystems are of the form of 
CAD models. 

In functional design, thcftmeti «ifl1 infrrgrtty nf th* eystMt\ 

40 and its subsystems are <umnUt*A and evaluated. VSDE 
supports mathematical representation or input/output map- 
ping of the subsystem functionaliry. The itnwtfoutput map~ 
ping can be of the form of a black box inside which the 
mapping is represented as a neural network, fuzzy logic 

45 system or knowledge based representation. All the sub- 
systems and components need not be modeled using the 
same modeling tecmnque. Same of fee subsystems can be 
represented mathematically, some of them re pre s e nte d as 
neural network models or some others as knowledge based 

so systems. This characteristics of VSDB is very useful in 
system integration studies because, in many cases sub- 
systems may not be designed by a single agency and some 
of the subsystems may be off-4fae-shelf products. 
In both geometry based design as well as functional 

23 design, SHG and SIDB defines the system structure and 
mterdependencies (FIG. 24). The geometric details as well 
as functional details of a design are two parallel aspects of 
SHG and SIDB (FIG. 26a). At any time the designer can 
view and edit the geometric details or functional details 
using corresponding design browsers. The design browsers 

60 are called Geometry Design Browsers (GDB) and Rmction 
Design Browsers (FDB). For making any changes in these 

in SHG and SIDB. 
Geometry Design Browsers 
65 The Geometry Design Browser (GDB) is an interactive 
editor that provides access to each individual components of 
a system. The designer can edit the SHG and SIDB also in 
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GDB. FIG. 25 shows an example user interface far GDB. ft dated with it). If the designer chose to examine this 
has three display windows and two panel windows. The subsystem, the FDB will look like the one in FIG. 28. 
designer can choose one of the three display windows for Unlike GDB, implementation of FDB does not require 
editing. For example, he/she can choose the Model Window sophisticated graphics manipulation libraries or display rou- 
and select any of the subsystems or components and arrange tines. Hie important software components of FDB are the 
mem anyway he/she de cides. Ccaresponding changes are Inpat Data Interface, Sub-System Model and Output Data 
made on the SHG and SIDB windows so mat the overall Interface. The designer has to specify the type of modeling 
s ystem is consistent with the hierarchy. Each of the sub- employed (mathematical representation, neural networks 
systems have an associated CAD model and the designer can etc.) so that me browser can make necessary changes in the 
select any one of these subsystems and edit its hierarchy and data interfacing. During the simulation stage, the designer 
components. For example, FIG. 2f shows the interface when 10 can monitor the input data, output data and any data flow at 
the designer has selected the Head Assembly subsystem. In any intenrjediate point of interest, specified through the user 
this interface only the selected subsystem and its compo- infprfWt* 

nents will be displayed and can be edited FDB allows two modes of operation; an off-line mode and 

Thus the designer can scan through each of the levels in an on-line mode, m off-line mode, the input data is provided 
the hierarchy or each of the subsystems in each of the 15 from a file and the output data as well as the specified 
hierarchy levels and do detailed design studies. If any of the intermediate results, are stored as data files. These data files 
geometric details of the subsystems are not acceptable, the can be visualized as graphs or charts later on. Id the case of 
de signer will be able to redesign mat subsystem and virtu- on-line mode the designer can visualize the results at the 
ally reintegrate the whole system again. output and i ntmnediate points through on-line visualization 

The GDB can inoocpocate 2D or 3D models of me windows, 
subsystems. In the case of 3D models, the designer can 20 Iinplementarion of Geometric and Function Design Brows- 
select any perspective view of the design by specifying the ers 

look sn ^ The Design Browsers are implemented in an Object 

Implementation Oriented environment with C-K/Java as the programming 

Hie GDB is implemented in an Object Oriented environ- eirviromnent The user interfaces are developed in X/Visual 
meat Each of the subsystems and their components are 23 C++. 

treated as an object Depending on the hkxarchy specified in Stage 4: Detailed System Analysis 
SHG and relationships specified in SIDB, some of these The final stage in VSDE is the analysis of the overall 
objects will be mheriting characteristics from their parent system. In Stage 3, VSDE allows the designer to design and 
objects. The model rendering and associated graphics integrate the subsystems and the cornponents of subsystems. 
m a nipulati ons ate done through World Toolkit libraries, » Stage 3 does not allow the designer to analyze the whole 
Function Design Browsers system with respect to the objectives and constraints set 

like GDB, Function Design Browser (FDB) is an inter- forth in Stages 1 andZ11iisfcatmvminte9ate4inStage4 
active editor which aQows the designer to design and of VSDE. Since all the design stags are integrated, the 
integrate system functionalities. The underlying subsystem <Wgnpr r*n gr> to any fif thr rnrfjer design stages and 
relationships are represented by the SHG and the SIDB. ^ make changes to the subsystems, components, performance 
FIG. 27 shows an example FDB for the system shown in characteristics or design goals and re-evaluate me entire 
FIG. 19. As in the case of GDB, FDB also has three display system. This feature of VSDE is extremely useful in appii- 
windows and two panel widows. The first difference canons involving design process consisting of many itera- 
between GDB and FDB is in the model window. In the case rive steps. Also, the entire system or any of its subsystems 
of functional design, in this window the system functional- can be simulated structurally as well as functionally during 
fries are represented with all the interrelationships. The 40 this design process and the design parameters can be optoV 
second difference is that dynamic simulation of the fane- mized. The representation of such a stages approach in 
tionalities is possible in FDB. Such a feature is not currently VSDB is illustrated in FIG. 29. Note mat the Stages 1 and 
incorporated in GDB. 2 can have inumple substages in each of them (FIG. 3) and 

Each of the subsystems are represented mtmematkalfy or VSDE allows the designer to go back to any of these 
through inrJuVc^itput models. VSDE supports three different 45 substages during the Stage 4 analysis, 
kinds of models; neural network representation, fuzzy logic The functional flow chart of Stage 4 is shown in FIG. 3*. 
systems and knowledge based system models. The design As in the case of the previous stags, analysis can be done 
environment is flexible enough to support a combination of based on geometry or functionalities. The characteristics of 
all the three models and mathematical representation the system, subsystem and their coinrxjoentsfcnnthemputs 
together. This is a unique property of VSDE. 50 to the ODSS and for the designed system the designer can 

Since the subsystems need not be designed inside VSDE, check whether the top level objectives are TTie niimber 
the designer may not be having control over the represen- of system characteristics needed for the evaluation depends 
tatrve format of some of the subsystems. Some of the on the ODSS model complexity. In some cases, the ODSS 
subsystems may be off-the-shelf products. The design envi- model may be inco r p ora ting inputs from the subsystem 
ronment supports integration of such hybrid subsystems and 55 levels too. Also, all me inputs to the ODSS need not be the 
their evaluation. Also, this property of VSDB is essential results of detailed design. Some effre inpife to ODSS rnay 
when it is used as a technology evaluation tool The tech- be from external sources. 

notogical advancements msubsyst^ The above aspect of VSDE is explained in FIG. 31. 

pedicted and the system evaluation tool should be able to Consider the example of Power Distribution System design 
integrate and study subsystems from different domains. (FIG. 21). Let Cost of the system is the higher level variable 

Some of the subsystems which has only geometrical 60 of most concern. During Stage land 2 of the design process, 
properties associated with them, will not be showing up on the designer would have made a decision model (as decision 
the functional design browsers. For example, in Power trees) representing the higher level variables (FIGS . 6 & 13), 
Distribution Circuits subassembly, the components Casing itiHtvting Cost If Cost is the only variable of concern, there 
and PCB may be having only geometrical properties asso- win be only one top most level node in the ODSS model, 
dated with it (unless, Casing is used for heat dissipation, 65 The inputs to the model will be design parameters such as 
grounding etc., or electrical resistance of PCB circuits is size of battery, weight of battery, motor power, motor size 
relevant; in which case they have electrical functions asso- etc, which arc the parameters decided during the h***^ 
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design phase in Stage 3. The ODSS model can also have 
external inputs such as cost of assembly; shipment cost/Dx 
etc. which are not design parameters. 

Daring the functional or geometric design stage, each of 
the nodes in the functional hierarchy or geometric hierarchy 
will be associated with more man one design parameters. 
Far example, the node Motor may be associated with size, 
weight and power, the node Casing may be associated with 
size and weight. The number of design parameters associ- 
ated with a node depends up on the refinement of the 
functional or geometric models. The node Motor by itself 
can represent a model hierarchy consisting of subnodes such 
as weight, size and power, ft is up to the designer to decide 
how refined the model should be and the design env ironment 
imposes no restriction on the complexity of the models 
being buift or the design tasks being considered. As indi- 
cated before, such a hierarchical representation of sub- 
systems and components, and their inmkmentatiGn based on 
Object Oriented principles provide VSDB amsiderabk flex- 
tbiliry in modeling and power on the overall design process. 
Model Dependency Matrix 

The interconnections of design parametcrs~to the ODSS 
models are defined through a Model Dependency Matrix 
(MDM> The MDM is similar to the SJDB in Stage 3, except 
that each of me elements in MDM may be associated with 
a submatrix- THs submatrix defines the intercoiuKctic^ c^ 
subnodes associated with that node. Such submatrices will 
exist only when multiple attributes are associated with the 
nodes in design hierarchy. For example, FIG. 32 shows the 
MDM for the example shown in FIG. 3#. The elements 
(Motor, var 8), (Battery, var 6), (Battery, var 2), (PCB, var 
6) and (Casing, var 5) have submatrices associated with 
mem. FIG. 33 shows some of those submatrices. 

Following the detailed design, the A^gmr can analyze 
the designed system against each of the conceptual level 
objectives (specified in ODSS, during Stage land 2). The 
designed system need not be the same as the ODSS opti- 
mized system because of geometrical or functional limita- 
tions of the subsystems and components. Some of these 
limitations maybe surfacing only during the detailed design 
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The VSDB user interface for Stage 4 allows the designer 
to go back to the ODSS knowledge based model and 
decision trees and change the hierarchy or variables, or 
change the operations in detailed design stage (Stage 3). 
FIG. 34 shows an example user interface for Stage 4. As in 
Stage 3, this interface also has three display windows and 45 
two panel windows. The display windows show the SHG/ 
Function Mode/Geometric Model, the decision model used 
in ODSS and the Model Dependency Matrix. Clicking on 
the SHG/Model window allows the designer to go back to 
Stage 3, for me detailed design process. CHckmg on the 
ODSS decision model allows the designer to change the 
decision modeL and cricking on the MDM window allows 
changing of the MDM matrix. Consistency of the changes is 
checked each time a change has happened and the informa- 
tion contained in all the three display windows need to be 
consistent with each other. 

What is claimed: 

1. A computer-implemented prototyping method compris- 
ing the steps of: 
identifying and selecting a design from a collection of 

alternate designs which best satisfies a set of conceptual 

level design specifications; 
opti miring characteristics of the design based on the 

conceptual level design specifications; 
modifying the specification's interactively using graphical 

interfaces for reevaluating and re-optimizing the 

designs; 
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simulating the functional and geometrical properties of 
the design and components of the design on a computer 
tismg grar^ical design browsers; 
analyzing a performance of the design against a set of 
design specifications and effecting a redesign by inter- 
actively selecting one of the previous design operations 
through the graphical user interfaces; 
wherein said identifying step includes; 

using a knowledge base system inrh^ing a user modi- 
fiable artificial intelligence based representation of a 
decision tree defined by an interconnected multi- 
level nodal Merarcfay having a strength assigned to 
each of the interconnections between nodes in the 
hierarchy; 

using a database tnrfmting a stnteA jfataK*^ rfprtren- 

tation of me functional details of the design alterna- 
tives under consideration by the user; the database 
representation being consistent with the multilevel 
nodal hierarchy of the knowledge based system; 
using a constraint solver mmkanented as a set of logic 
programs which evaluates the user specified con- 
straints on the nodal variables in the nodal hierarchy 
against the functional details of the design aitema- 
tives represented in the database ajul computed nodal 
strengths during an evaluation process; 
using a graphical user mterfarc including a first edit 
window for designing, displaying and revising the 
decision tree in response to user input commands 
through a computer keyboard and mouse; and a 
second edit window for displaying the database 
representation and revising the database representa- 
tion in response to user input commands; and a third 
edit window for displaying and revising the specifi- 
cations against which the design are evaluated in 
response to user input commands; and fmlher includ- 
ing a set of gravities panels for displaying un^enne- 
diate and final results of die evaluation process; 
wherein the said optimization step includes: 

using a neural network based representation of the 
nodal hierarchy with the interconnection strengths 
of the hierarchy mmlemented as weights in the 
neural networks and the user specifications repre- 
sented as an objective function at the output layer 
of the neural network, and the input variables 
corresponding to the functional details of the 
design being optimized stored in the database; 
using another graphical user interface including a 
front end for the user to specify the number of 
cycles through which the optimization is 
performed, and yet another graphical interface for 
specifying whether the optimization is performed 
on a single design or on a set of designs, and a set 
of colored graphics panels for displaying me inter- 
mediate and final results of the optimization, and 
another graphical interface to allow the user to 
revise design specifications and re-optimize the 
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2. A method according to claim l,wherem said simulation 
step includes: 

solving a set of inamematical equations representing the 
functional behavior of the components, imrJm^tf^ 
using software programs residing in the computer 
memory, for design of components of (he design; 

incorporating components designed externally, without 
the help of software programs mentioned above, into 
the computer memory; 

specifying the interrelationships of design components in 
terms of their functional properties as well as geometri- 
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cal properties employing a set of matrix based data- 
bases and hierarchy graphs defined by a multi-level 
nodal hierarchy having each of the nodes representing 
a component of the design; 

browsing the functionality and geometry of the design 
using a set of graphical interfaces in which the designs, 
its functional hierarchy, and its geometrical hierarchy 
are displayed; in which the user can select any one of 
the components shown on the display and examine or 
revise corresponding hierarchy. 

3. A ooffirrKit^T-inyleinented prototyping method compris- 
ing the steps of: 

identifying and selecting a design from a collection of 
alternate designs which best satisfies a set of conceptual 
level design specifications; 

optimizing characteristics of the design based on the 
conceptual level design specifications; 

modifying the specifications interactively using graphical 
interfaces for reevaluating and re-optimizing the 
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simulating the functional and geometrical properties of 
the design and components of the design on a computer 
using graphical design browsers; 
analyzing a performance of the design against a set of 25 
design specifications and effecting a redesign by inter- 
actively selecting one of the previous design operations 
through the graphical user interfaces; 
wherein said simulation step includes: 
solving a set of mathematical equations representing 30 
the functional behavior of the components, imple- 
mented using software programs residing in the 
computer memory, for design of components of the 
design; 

incorporating components designe d externally; without 33 
the help of said software programs, into the com- 
puter memory; 

specifying the interrelationships of A^tgn components 
in terms of their functional properties as well as 
geometrical properties employing a set of matrix 
based databases and hierarchy graphs defined by a 
multi-level nodal hierarchy having each of the nodes 
representing a component of the design; 

browsing the functionality and geometry of the design 
using a set of graphical interfaces in which the 
designs, its functional hierarchy, and its geometrical 
hierarchy are displayed; in which the user can select 
any one of the components shown on the display and 
examine or revise a oarresponding hierarchy. 
4. A CQmputer-inipleniented jMutotypiiig method compris- 
ing the steps of: 
identifying and selecting a design from a collection of 

alternate designs which best satisfies a set of conceptual 

level design specifications; 
optimizing characteristics of the design based on the 

conceptual level design specifications; 
modifying the specifications interactively using graphical 

interfaces for reevaluating and re-optimizing the 

designs; 

simulating the functional and geometrical properties of 
the design and components of the design on a computer 
using graphical design browsers; 

analyzing a performance of the design against a set of 
design specifications and effecting a redesign by inter 
actively selecting one of the previous design c^jerations 
through the graphical user interfaces; 
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wherein said identifying step includes: 
using a knowledge base system including a user modi- 
fiable artificial intelligence based representation of a 
decision tree defined by an interconnected multi- 
level nodal hierarchy having a strength assigned to 
each of the interconnections between nodes in the 
hierarchy; 

using a database including a stored database represen- 
tation of the functional details of the design alterna- 
tives under consideration by the user, the database 
representation being consisrrait with the multi-level 
nodal hierarchy of the knowledge based system; 
using a constraint solver implemented as a set of logic 
progr am s which evaluates the user specified con- 
straints on the nodal variables in the nodal hierarchy 
against the functional of the ^ifigp uttrma- 

tives represented in the database and c«nputcdiKxlal 
strengths during an evaluation process; 
using a graphical user interface including a first edit 
window for designing, displaying and revising the 
decision tree in response to user input commands 
through a computer keyboard and mouse; and a 
second edit window for displaying the database 
representation and revising the. database representa- 
tion in response to user input commands; and a third 
edit window for displaying and revising the specifi- 
cations against which the design are evaluated in 
. response to user input cominands;andfnrmerinclndV 
ing a set of graphics panels for displaying interme- 
diate and final results of the evaluation process; 
wherein said simulation step includes: 
solving a set of mamematkal equations representing 
me functional behavior of the components, imple- 
mented using software programs residing in the 
computer memory; for of components of 

the design; 

mcorporating components designed externally, with- 
out the help of software programs mentioned 
above, into the computer memory; 

specifying the interrdation ships of design compo- 
nents in terms of their functional properties as well 
as geometrical properties employing a set of 
matrix based databases and hierarchy graphs 
defined by a multi-level nodal hierarchy having 
each of the nodes representing a component of the 
design; 

browsing die functionality and geometry of the 
design using a set of graphical interfaces in which 
the designs, its functional tferarchy, and its geo- 
metrical hierarchy are displayed; m which the tiser 
can select any one of the components shown on 
me display and examine or revise corresponding 
hierarchy. 

5. A method according to claim 4, wherein the said 
analyzing step includes: 

integrating the hierarchical representation of the proper- 
ties with the knowledge base system and its decision 
tree hierarchy, implemented in the wp^mter memory; 

analyzing me sensitivity of each of the components 
against the rf^gjgn specifications represented through 
the knowledge base system, its nodal hierarchy, and 
against the user specified constraints; 

visualizing the performance of the design graphically on 
the computer screen using multiple graphics panels, 
which capability f bar the user to interactively select each 
of the components of the design and visualize its 
functional as well a geometrical rttrfbrmance; 



5,754 

19 

the user to stop the analysis process and store the condi- 
tions on to the computer memory, and graphically 
select any of said step, and revise associated 
specifications, nodal hierarchy, components hierarchy 
or the databases; and independently perform each of the 5 
steps with the conditions stored in the computer 
memory. 

6. A computerized prototyping system composing: 
identifying means for identifying and selecting a design 
from a collection of alternate designs winch best sat- 10 
isfies a set of conceptual level design specifications; 
optimizing means for optimizing characteristics of me 
design based on the conceptual level design specifica- 
tions; 

modifying means for modifying the specifications inter- 15 
actively using graphical interfaces for re-evaluating 
and re-optinriring the designs; 

gimnforing nwam« for &tmnixtfng functional and geometri- 
cal properties of the design and components of me ^ 
design on a computer using graphical design browsers; 

analyzing means for analyzing a performance of (he 
design against a set of design specifications and effect- 
ing a redesign by interactively selecting one of me 
previous design operations through the graphical user 25 
interfaces; 

wherein said identifying means includes: 
a knowledge base system rndnding a user modifiable 
artificial intelligence based representation of a deci- 
sion tree defined by an interconnected multi-level 30 
nodal hierarchy having a tfrmgtfi iwnrigwH ta ^trfi 
the interconnections hetwegn imdM in tht» himrrhy 
a database including a stored database representation of 
the functional details of design alternatives under 
consideration by the user, the database representa- 35 
tion being consistent with the muhi-levcl nodal hier- 
archy of the knowledge based system; 
a constraint solver implemented as a set of logic 
programs which evaluates user specified constraints 
on nodal variables in the nodal hierarchy against the 40 
functional details of the design alternatives repre- 
sented in the database and computed nodal strengths 
during an evaluation process; and 
a graphical user interface including a first edit window 
for designing, displaying and revising the decision 45 
tree in response to user input commands through a 
computer keyboard and mouse; and a second edit 
window for displaying the database representation 
and revising the database representation in response 
to the user input commands; and a third edit window 50 
for displaying and revising the specifications against 
which the design are evaluated in response to the 
user input commands; and further including a set of 
graphics panels for displaying the intwmw*tf»te and 
final results of the evaluation; 55 
wherein the said optimizing means includes: 
a neural network based representation of the nodal 
hierarchy with me intercorinection strengths of the 
hierarchy iniplemented as weights in the neural 
network and the user specifications represented as ft 
an objective function at the output layer of me 
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neural network, and the input variables corre- 
sponding to the functional details of the design 
being optimized stored in the database; 
another graphical user interface including a front end 
for the user to specify a number of cycles through 
which the optimization is performed, and yet 
another graphical interface for specifying whether 
the optimization is performed on a single design or 
on a set of designs, and a set of colored graphics 
panels for displaying the htferrnediatr and final 
results of the optimization, and another graphical 
interface to allow the user to revise design speci- 
fications andie~optimize the dwtign*- 
7. A <*"iipMtm*zfd prototyping system comprising: 
a knowledge base system including a user modifiable 
artificial intelligence based representation of a decision 
tree defined by an interconnected multi4evel nodal 
hierarchy having a strength assigned to each of the 
interconnections between nodes in the hierarchy; 
a database including a stored database representation of 
the functional details of design alternatives under con- 
sideration by the user, the database representation being 
consistent with the multi-level nodal hierarchy of the 
knowledge based system; 
a constraint solver implemented as a set of logic progr am s 
which evaluates user specified constraints on nodal 
variables in the nodal hierarchy against the functional 
details of the design alternatives represented in the 
database and computed nodal strengths during an 
evaluation process; 
a graphical user interface indndinganmeditwindewfor 
designing, displaying and revising me decision tree in 
response to user input commands through a coaupute r 
. keyboard and mouse; and a second edit window for 
displaying the database representation and revising me 
database representation in response to me user input 
commands; and a third edit window for displaying and 
revising the specifications against which the design are 
evaluated in response to the user input commands; 

farther tnr4nr4ing nse* nf graphfr^ pflntffc for displayin g 

the intermediate and final results of the evaluation; 

a neural network based representation of the nodal hier- 
archy with the interconnection strengths of the hierar- 
chy implemented as weights in the neural network and 
the user specifications represented as an objective func- 
tion at the output layer of the neural network, and die 
input variables corresponding to the functional details 
of the design being optimized stored in the database; 

another graphical user interface including a front end for 
the user to specify the number of cycles *%""gft which 
the optimization is performed, and yet another graphi- 
cal interface for specifying whether tfm nr *imfa»tin n k 
performed on a single design or on a set of designs, and 
a set of colored graphics panels for displaying the 
intennediate and final results of the optimization, and 
another graphical interface to allow the user to revise 
design specifications and le-orrtnnize the *fr**g*«, 

» * * » * 



